> I wasn't talking about VESA acceleration, but having the a user land
> binary that can do everything for fbdev, including mode sets, palette
> programming, acceleration (for text modes, scrolling etc) and
> anything else fbdev does. This would not be implementing using VESA
> services, but instead be implemented via user land daemon chipset
> drivers that go native to the hardware.
It is called XFree86. If you can have deamon that does this then
why have fbdev at all. Reason is because some platforms don't have
any concept of a text mode. You have to use a graphical mode to emulate a
text console system. Also on intel platforms the IO space is part of
the regular memory space. On other platforms this is not the case. So
tricks using /dev/mem like Xfrre86 uses on intel platforms will not
work on these platforms. So you need kernel support to make these IO
regions avaliable to userland. This includes the framebuffer memory
itself. Look at the fb_write and fb_read functions in fbcon.h. These
functions are used to place the pixel value we have into the framebuffer
memory. On intel you could this on the video memory where *dst is some
area in the framebuffer.
*dst |= last << shift_left;
On a alpha this would crap out. You need to the following instead.
writel (readl(dst) | (last << shift_left), dst);
Thats why for a while fbcon-cfbX didn't work on alpha systems.
> The obvious question is 'why', when you can already do chipset
> specific drivers in the kernel. The answer to that is twofold:
>
> 1. You can more easily replace the drivers or update them without
> having to modify your kernel at all (and it is more protected
> since the fbdev driver can't cause a kernel oops).
You could just compile it as a module and insmod it if you change the
code. What you can't do is change the API unless you want to patch your
own kernel. If you want to have this patch become the standard then you
post it to the linux-fbdev list. We review it and test it. Then submit it
to Linus. Also a badly writing fbdev driver can cause a oops.
> 2. The source for the drivers does not need to be under GPL.
Modules don't need to be under GPL.
> The second issue is very important, because with XFree86 4.0's new
> modular chipset driver architecture, it may well be possible to build
> this user land daemon such that it can use standard XFree86 4.0
> chipset driver. It is simply not possible to do this in the kernel,
> because XFree86's license is not GPL compatible (and never will be).
You are thinking in reverse.
> This would provide a mechanism to completely avoid duplication of
> work, and more importantly the XFree86 drivers would not have to
> fight with the framebuffer console drivers since there would really
> only be one driver running the graphics card in the system (ie:
> save/restore state becomes a *lot* easier).
Right. Fbdev should be handling it only. I hope to see down the road all
chipsets supported by XFree86 ported to fbdev.
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:16 EST