(5.4-i386) framebuffer console

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

(5.4-i386) framebuffer console

Adam Jensen
I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html)

"wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer
console."

drm supports the radeon driver and I have an old Thinkpad T60 with:

vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
radeondrm0 at vga1: apic 1 int 16

Cool. So I guess setting up a framebuffer console at 1024x768 might go
something like this:

wsfontload <clueless>
wsconscfg -dF 5
wsconscfg -f /dev/drm0 -e vt100 -t <hmm> 5

Yeah, this needs a little work. Has anyone managed to pull this off?

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Philip Guenther-2
On Fri, Dec 13, 2013 at 9:09 PM, Adam Jensen <[hidden email]> wrote:

> I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html)
>
> "wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer
> console."
>
> drm supports the radeon driver and I have an old Thinkpad T60 with:
>
> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
> radeondrm0 at vga1: apic 1 int 16
>
> Cool. So I guess setting up a framebuffer console at 1024x768

What does this *mean*?  For example, how do you plan to draw in this
1024x768 framebuffer?


> might go something like this:
>
> wsfontload <clueless>
> wsconscfg -dF 5
> wsconscfg -f /dev/drm0 -e vt100 -t <hmm> 5
>
> Yeah, this needs a little work. Has anyone managed to pull this off?

"Hi, I'm going to

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
On 12/14/2013 01:36 AM, Philip Guenther wrote:

> On Fri, Dec 13, 2013 at 9:09 PM, Adam Jensen <[hidden email]> wrote:
>> I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html)
>>
>> "wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer
>> console."
>>
>> drm supports the radeon driver and I have an old Thinkpad T60 with:
>>
>> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
>> radeondrm0 at vga1: apic 1 int 16
>>
>> Cool. So I guess setting up a framebuffer console at 1024x768
>
> What does this *mean*?  For example, how do you plan to draw in this
> 1024x768 framebuffer?
>

A framebuffer console, as its name implies, is a text console running on
top of the framebuffer device. It has the functionality of any standard
text console driver, such as the VGA console, with added features that
can be attributed to the graphical nature of the framebuffer device. It
probably allows high resolution text, varying font types, multi-colored
fonts, blending, aliasing, and any other feature made available by the
underlying graphics card.

It looks like it's a very new feature in OpenBSD and I really have
little idea (at the moment) of what's possible/available.

If anyone is familiar the framebuffer console and how to configure it
and manipulate it, a little tutorial will be much appreciated!

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
In reply to this post by Adam Jensen
On 12/14/2013 12:09 AM, Adam Jensen wrote:

> I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html)
>
> "wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer
> console."
>
> drm supports the radeon driver and I have an old Thinkpad T60 with:
>
> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
> radeondrm0 at vga1: apic 1 int 16
>

After closer inspection, wsdisplay attaches to inteldrm specifically,
not just generic drm. So I guess radeondrm isn't suitable for a
framebuffer console. Luckily, I have a machine with the Intel 945G
Chipset that I can re-task and dedicate to OpenBSD tinkering. Game on.

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Gabriel Guzman-2
On 12/14, Adam Jensen wrote:

> On 12/14/2013 12:09 AM, Adam Jensen wrote:
> >I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html)
> >
> >"wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer
> >console."
> >
> >drm supports the radeon driver and I have an old Thinkpad T60 with:
> >
> >vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
> >radeondrm0 at vga1: apic 1 int 16
> >
>
> After closer inspection, wsdisplay attaches to inteldrm specifically, not
> just generic drm. So I guess radeondrm isn't suitable for a framebuffer
> console. Luckily, I have a machine with the Intel 945G Chipset that I can
> re-task and dedicate to OpenBSD tinkering. Game on.

Not sure if it made it in time for 5.4 or not, but running a current
snapshot:

radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6320" rev 0x00: apic
0 int 18
drm0 at radeondrm0
radeondrm0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M
used)
radeondrm0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
radeondrm0: 1920x1080
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using
wskbd0

radeondrm framebuffer just works.

gabe.

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
On 12/14/2013 02:57 PM, Gabriel Guzman wrote:
> wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using
> wskbd0
>

Did you get a framebuffer (no X11) console working with a decent
resolution font and [much] more than 25 lines of 80 characters? If so,
how did you do it - what's your recipe?

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Gabriel Guzman-2
On 12/14, Adam Jensen wrote:
> On 12/14/2013 02:57 PM, Gabriel Guzman wrote:
> >wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using
> >wskbd0
> >
>
> Did you get a framebuffer (no X11) console working with a decent resolution

radeondrm0: 1920x1080  

> font and [much] more than 25 lines of 80 characters? If so, how did you do

51 lines, 161 characters.

> it - what's your recipe?

just boot the machine (: no tweaking required.  
I guess if it's not working for you, then something is wrong, since I
didn't have to do anything to get it working on my end.

I haven't tried to adjust the framebuffer settings, or change the
font as the default is fine for me.

gabe.

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Juan Francisco Cantero Hurtado
On Sat, Dec 14, 2013 at 04:46:58PM -0500, Gabriel Guzman wrote:

> On 12/14, Adam Jensen wrote:
> > On 12/14/2013 02:57 PM, Gabriel Guzman wrote:
> > >wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using
> > >wskbd0
> > >
> >
> > Did you get a framebuffer (no X11) console working with a decent resolution
>
> radeondrm0: 1920x1080  
>
> > font and [much] more than 25 lines of 80 characters? If so, how did you do
>
> 51 lines, 161 characters.
>
> > it - what's your recipe?

Update to -current or wait to OpenBSD 5.5.

>
> just boot the machine (: no tweaking required.  
> I guess if it's not working for you, then something is wrong, since I
> didn't have to do anything to get it working on my end.
>
> I haven't tried to adjust the framebuffer settings, or change the
> font as the default is fine for me.
>
> gabe.
>

--
Juan Francisco Cantero Hurtado http://juanfra.info

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
In reply to this post by Gabriel Guzman-2
On 12/14/2013 04:46 PM, Gabriel Guzman wrote:

> On 12/14, Adam Jensen wrote:
>> Did you get a framebuffer (no X11) console working with a decent resolution
>> font and [much] more than 25 lines of 80 characters? If so, how did you do
>> it - what's your recipe?
>
> just boot the machine (: no tweaking required.
> I guess if it's not working for you, then something is wrong, since I
> didn't have to do anything to get it working on my end.
>
> I haven't tried to adjust the framebuffer settings, or change the
> font as the default is fine for me.
>

For the sake of others who might also be confused by this, the
framebuffer console is probably configured and *on by default* when
5.4-release (or -stable or -current) is installed on machine with an
appropriate *intel* graphics device. I say "probably" because I haven't
verified this on an intel graphics equipped machine. Machines without an
appropriate graphics device won't/can't have a framebuffer console (yet).

Apparently, a framebuffer console is configured and *on by default* when
5.4-current is installed on machine with an appropriate *radeon*
graphics device. I upgraded a radeon equipped machine to 5.4-current
this evening and got to see the framebuffer console in action, briefly
(the kernel panicked during boot). The console text is still quite a bit
larger than I would like.

If anyone has knowledge of how the framebuffer console is configured and
controlled, a short tutorial would be grand!

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
On 12/15/2013 08:16 PM, Adam Jensen wrote:

> On 12/14/2013 04:46 PM, Gabriel Guzman wrote:
>> On 12/14, Adam Jensen wrote:
>>> Did you get a framebuffer (no X11) console working with a decent
>>> resolution
>>> font and [much] more than 25 lines of 80 characters? If so, how did
>>> you do
>>> it - what's your recipe?
>>
>> just boot the machine (: no tweaking required.
>> I guess if it's not working for you, then something is wrong, since I
>> didn't have to do anything to get it working on my end.
>>
>> I haven't tried to adjust the framebuffer settings, or change the
>> font as the default is fine for me.
>>
>
> For the sake of others who might also be confused by this, the
> framebuffer console is probably configured and *on by default* when
> 5.4-release (or -stable or -current) is installed on machine with an
> appropriate *intel* graphics device. I say "probably" because I haven't
> verified this on an intel graphics equipped machine. Machines without an
> appropriate graphics device won't/can't have a framebuffer console (yet).
>
> Apparently, a framebuffer console is configured and *on by default* when
> 5.4-current is installed on machine with an appropriate *radeon*
> graphics device. I upgraded a radeon equipped machine to 5.4-current
> this evening and got to see the framebuffer console in action, briefly
> (the kernel panicked during boot). The console text is still quite a bit
> larger than I would like.
>
> If anyone has knowledge of how the framebuffer console is configured and
> controlled, a short tutorial would be grand!
>
>

Here is a dmesg for the machine that panicked with today's pull & build
of 5.4-current. 5.4-release was reinstalled to get the dmesg.

[dmesg]: http://pastebin.com/raw.php?i=PtQdaE5R

Reply | Threaded
Open this post in threaded view
|

Re: (5.4-i386) framebuffer console

Adam Jensen
In reply to this post by Adam Jensen
On 12/15/2013 08:16 PM, Adam Jensen wrote:

> For the sake of others who might also be confused by this, the
> framebuffer console is probably configured and *on by default* when
> 5.4-release (or -stable or -current) is installed on machine with an
> appropriate *intel* graphics device. I say "probably" because I haven't
> verified this on an intel graphics equipped machine. Machines without an
> appropriate graphics device won't/can't have a framebuffer console (yet).
>
> If anyone has knowledge of how the framebuffer console is configured and
> controlled, a short tutorial would be grand!
>

I now have 5.4-stable running on a machine with an intel graphics device
and the framebuffer console is indeed on by default.

[dmesg]: http://pastebin.com/raw.php?i=eKgZzNa8

When the monitor is connected directly to the machine - rather than the
KVM switch - the machine boots with 1600x1200 resolution and there is
plenty of text on the screen. At this resolution the text size is almost
perfect for me but the default font is a bit thick, jagged, and overly
stylized for my taste.

Has anyone figured out how to configure the framebuffer console?