development of framebuffer driver hi res console
ketracel
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
--
Philip Paeps Please don't Cc me, I am
phi...@freebsd.org subscribed to the list.
[looking at photos of a house]
<skel> big house all nice and well, but big garden looks like effort
<skel> all big things look like effort
<SuperEgg> skel - good luck in your sex life then
Peter Jeremy
>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.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
Eric Anholt
> On 2008-05-16 19:15:19 (+0800), ketracel <ketr...@internode.on.net> wrote:
> > 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.
--
Eric Anholt anh...@FreeBSD.org
er...@anholt.net eric....@intel.com
Wilkinson, Alex
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.
Sam Fourman Jr.
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
On 23/05/2008, at 2:21 PM, Sam Fourman Jr. wrote:
> 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.
Eric Anholt
> 0n Tue, May 20, 2008 at 09:19:43AM -0700, Eric Anholt wrote:
>
> >On Tue, 2008-05-20 at 09:46 +0200, Philip Paeps wrote:
> >> On 2008-05-16 19:15:19 (+0800), ketracel <ketr...@internode.on.net> wrote:
> >> > 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.
Jeremie Le Hen
On Fri, May 23, 2008 at 01:21:50AM -0500, Sam Fourman Jr. wrote:
> 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.
> 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,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
Eric Anholt
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
> 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
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.
--
Michel TALON
kip...@gmail.com
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.