development of framebuffer driver hi res console

[ketracel]

Any FreeBSD developers out there working on a Framebuffer driver
which provides modern high resolution modes (including widescreen)
for the system console?

Amd64 platform currently has no options to change the primitive 80x25
mode text console as VESA is not supported.

Mac OS X uses native display resolutions as soon as the machine is
powered on.

Linux supports a Framebuffer driver for native LCD resolution at the
console

OpenSolaris uses a Framebuffer driver which immediately detects
screen resolution.

[Philip Paeps]

Any FreeBSD developers out there working on a Framebuffer driver which
provides modern high resolution modes (including widescreen) for the system
console?

Not specifically working on a high-res framebuffer, but I'm working on
divorcing the framebuffer from syscons. Once that work is done, it should be
possible to write more "advanced" framebuffer drivers.

- Philip

[Peter Jeremy]

Post by Philip Paeps
Not specifically working on a high-res framebuffer, but I'm working on
divorcing the framebuffer from syscons. Once that work is done, it should be
possible to write more "advanced" framebuffer drivers.

You might like to look at tga(4) [in the Attic] for some hints on
interfacing to raw framebuffers.

[Eric Anholt]

Post by Philip Paeps

Any FreeBSD developers out there working on a Framebuffer driver which
provides modern high resolution modes (including widescreen) for the system
console?

Not specifically working on a high-res framebuffer, but I'm working on
divorcing the framebuffer from syscons. Once that work is done, it should be
possible to write more "advanced" framebuffer drivers.

And the graphics developers are already porting their drivers to the
kernel to provide the framebuffer part. What it would take to port that
to FreeBSD has been outlined elsewhere.

[Wilkinson, Alex]

Post by Eric Anholt

Post by Philip Paeps

Any FreeBSD developers out there working on a Framebuffer driver which
provides modern high resolution modes (including widescreen) for the system
console?

Not specifically working on a high-res framebuffer, but I'm working on
divorcing the framebuffer from syscons. Once that work is done, it should be
possible to write more "advanced" framebuffer drivers.

And the graphics developers are already porting their drivers to the
kernel to provide the framebuffer part. What it would take to port that
to FreeBSD has been outlined elsewhere.

Can someone actually define what is meant as "framebuffer" as opposed to VESA ?

I have physically seen OSs such as gentoo that have a framebuffer (pretty
consoles) but I have never ever known what a "framebuffer" is in the context of
VTYs.

Anyone care to post a nutshell summary ?

-aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

[Eric Anholt]

Post by Wilkinson, Alex

Post by Eric Anholt

Post by Philip Paeps

Any FreeBSD developers out there working on a Framebuffer driver which
provides modern high resolution modes (including widescreen) for the system
console?

Not specifically working on a high-res framebuffer, but I'm working on
divorcing the framebuffer from syscons. Once that work is done, it should be
possible to write more "advanced" framebuffer drivers.

And the graphics developers are already porting their drivers to the
kernel to provide the framebuffer part. What it would take to port that
to FreeBSD has been outlined elsewhere.

Can someone actually define what is meant as "framebuffer" as opposed to VESA ?
I have physically seen OSs such as gentoo that have a framebuffer (pretty
consoles) but I have never ever known what a "framebuffer" is in the context of
VTYs.
Anyone care to post a nutshell summary ?

A framebuffer's a collection of pixels. For consoles, that means not
VGA where you store a collection of characters that are looked up
through a font to produce pixels.

For DRM modesetting, we don't use VESA at all, since it's a terrible
interface and routinely under-tested for modern chips (since Windows
doesn't use it, it doesn't really work). Instead, we write native
device-specific modesetting, with all the featureset and power savings
of the native X driver you've been running in the past.

[Sam Fourman Jr.]

Amd64 platform currently has no options to change the primitive 80x25 mode
text console as VESA is not supported.

for what it is worth, I run my system console like this:

in my kernel conf file I put

options VESA # Enable VESA Mode
options SC_PIXEL_MODE #
options SC_HISTORY_SIZE=1000 #
options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) #
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) #
options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK) #
options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTBLUE|BG_BLACK) #

and in mt /etc/rc.conf I have

allscreens_flags="MODE_280"



note you should man vidcontrol before doing this.

just type vidcontrol -i at your system console for the correct mode.

it isn't like gentoo or fedora, but it works for me.
I would REALLLY like to see better frame buffer support in FreeBSD

Sam Fourman Jr.

[ketracel]

Post by Sam Fourman Jr.
Amd64 platform currently has no options to change the primitive 80x25 mode
text console as VESA is not supported.
I would REALLLY like to see better frame buffer support in FreeBSD
Sam Fourman Jr.

This becomes increasingly important as we move away from BIOS based
machines. New systems will be using EFI 2.0/2.1 spec and as such support
the Graphics Output Protocol which is set to replace the
functionality that
currently exists with VGA hardware and its corresponding video BIOS.

The Graphics Output Protocol provides the EFI OS loader access to a
hardware frame buffer and enough information to allow the OS to
draw directly to the graphics output device.

[Jeremie Le Hen]

Hi,

Post by Sam Fourman Jr.
and in mt /etc/rc.conf I have
allscreens_flags="MODE_280"
note you should man vidcontrol before doing this.
just type vidcontrol -i at your system console for the correct mode.

I've always been puzzled by vidcontrol(8). I've only been able to use
80x50.

Using "vidcontrol -i mode", I get 98 modes. If I try MODE_292
(1280x1024x32), I get the following message:
% vidcontrol: cannot active raster display: Inapropriate ioctl for device

And this is the case for most of them.

Post by Sam Fourman Jr.
it isn't like gentoo or fedora, but it works for me.
I would REALLLY like to see better frame buffer support in FreeBSD

My experience with Linux framebuffer is quite bad. I always disable it
since backward scrolling (using less) is really, really slow. If
there happen to be a similar feature on FreeBSD, I hope we won't have
this problem :).

Regards,

[Eric Anholt]

Post by Jeremie Le Hen
Hi,

Post by Sam Fourman Jr.
and in mt /etc/rc.conf I have
allscreens_flags="MODE_280"
note you should man vidcontrol before doing this.
just type vidcontrol -i at your system console for the correct mode.

I've always been puzzled by vidcontrol(8). I've only been able to use
80x50.
Using "vidcontrol -i mode", I get 98 modes. If I try MODE_292
% vidcontrol: cannot active raster display: Inapropriate ioctl for device
And this is the case for most of them.

Post by Sam Fourman Jr.
it isn't like gentoo or fedora, but it works for me.
I would REALLLY like to see better frame buffer support in FreeBSD

My experience with Linux framebuffer is quite bad. I always disable it
since backward scrolling (using less) is really, really slow. If
there happen to be a similar feature on FreeBSD, I hope we won't have
this problem :).

Modeling anything after linux fbdev would be a terrible idea. That code
should have died years ago, but a real modesetting model is only being
introduced now, sadly.

As for your specific performance issue, that's probably just due to the
developers of fbdev not understanding how graphics work, and trying to
memcpy around in framebuffer. Don't do that. You can memcpy from main
memory into framebuffer plenty fast, though, so no device-specific
acceleration is needed in console code.

[Michel Talon]

Post by Jeremie Le Hen
I've always been puzzled by vidcontrol(8). I've only been able to use
80x50.
Using "vidcontrol -i mode", I get 98 modes. If I try MODE_292
% vidcontrol: cannot active raster display: Inapropriate ioctl for
% device

This is not my experience. On my laptop, which is equipped with an Intel
integrated video,
agp0: <Intel 82945GM (945GM GMCH) SVGA controller>
i use the following in /etc/rc.conf:
allscreens_flags="MODE_356 green black"

This gives the *maximal* resolution of the screen and an extremely nice
display, with very fine fonts, better that what i have under Linux.
This is one of the hardware things which work very well under FreeBSD.

[k***@gmail.com]

Hello everyone,

I am also very interested in this feature.
Basically, I'd like to use FreeBSD in console only, in high resolution, without having to use X11.

Therefore, a framebuffer console is what I need.

What is the status on this? How can I help?

Thanks.

Post by Michel Talon

Post by Jeremie Le Hen
I've always been puzzled by vidcontrol(8). I've only been able to use
80x50.
Using "vidcontrol -i mode", I get 98 modes. If I try MODE_292
% vidcontrol: cannot active raster display: Inapropriate ioctl for
% device

This is not my experience. On my laptop, which is equipped with an Intel
integrated video,
agp0: <Intel 82945GM (945GM GMCH) SVGA controller>
allscreens_flags="MODE_356 green black"
This gives the *maximal* resolution of the screen and an extremely nice
display, with very fine fonts, better that what i have under Linux.
This is one of the hardware things which work very well under FreeBSD.
--
Michel TALON