Menu
▾
▴
linux-fbdev-devel
|
From: Sottek, M. J <mat...@in...> - 2001-11-17 00:28:38
|
>So what I need is the latest drivers from people so they can be
>ported over. I also want to>know what people needed for the fbdev
>layer as well as the input layer. I see some email about DDC
>support for example. Please let me know what you need. Thank you.
James,
Sorry to get such a late jump on giving input, but we can only
assume to have plenty of time before 2.6.x. Here is some input.
#1 Monitor timings/ mode setting is quite poor in 2.4.x. I haven't
looked at what you have so far but here are some points that
should be considered.
* Monitor timings are something that should be determined between
the driver and the monitor. Users and higher level api's should
not have anything to do with this. The driver I am working on
now has a fixed set of timings that it supports. When set_var
requests a new mode the closest match is found. It is key to
let the driver have it's own mode table. I also will eventually
parse EDID to add modes to my tables is the monitor needs
something special that I can support. To aid in code reuse you
should just provide a function that parses EDID data into an
edid data structure (Something like this was discussed a few
day ago)
* The user api needs to move away from timings all together.
The user should be able to select a refresh rate from a provided
list (negotiated between monitor and driver). It won't be long
before timings are no longer used in hardware, and the only thing
left to adjust will be refresh.
#2 Complete separation of data structures. The var and fix structures
need rework badly. All things that are not explicitly needed by
a higher level api should not be in there. Those things belong
in the driver private data structures (It doesn't matter that
nearly everyone will have an mmio pointer, it doesn't belong in
a public data structure)
* The software fallback functions should be set up in a more
explicit way to keep these pointers out of other people's hands.
For example, the console functions (putc, putcs etc) should
be done something like this.
fb->console_ops = create_generic_console_ops(base,pitch,depth);
or use a hardware specific set as you would today.
* I've seen mention of this in some posts but clearly the fb
driver should not be tied in any way to the console. My driver
has all the hardware functions totally independent of the
interface. The fbcon is an interface provided on top of a
graphics driver. They are currently way too connected, and
in my opinion this is one reason that a lot of the X & DRI
developers are not interested in combining efforts. The
result of console + graphics driver looks nothing like a
graphics driver and isn't appealing as a base driver to expand
on.
#3 Don't try to wrap everything in a hardware independent API. Some
hardware is going to support things that others don't. Take for
instance "mirroring". The i810 can do this on the CRT + a TV or
FP depending on what is connected. But the modes that can be
supported are very limited and mucking up a mode API with this
type of thing only makes a mess for everyone. Better to allow
a hardware specific switch to alter the output device and just
allow the driver to limit the available modes based on this
hardware specific switch. In MS this is like the display
properties dialog. The advanced options are dialogs written
specific for the hardware. We could just have a set of guidelines
for altering hardware specific configurations so that a command
line utility or GUI could be made to control them.
#4 It would certainly be nice to combine the drm code into the fb
code. NOTE: I wouldn't want to do this until the drivers are
organized like graphics drivers instead of consoles. There is
too much overlap now and it would just make for a really large
mess. Most of the dri enabled X drivers already have a different
code path for driver init than without dri so making the X servers
use fb+dri wouldn't be a such an issue. The main goal here would
be to eventually have a graphics driver setup that is easy to
configure. 1 kernel driver + 1 X driver == success. not 1 vga
driver + 1 fbcon driver + 1 drm driver + 1 X driver.
This is enough for discussion now,
-Matt
|
|
From: James S. <jsi...@tr...> - 2001-11-24 16:52:14
|
> #1 Monitor timings/ mode setting is quite poor in 2.4.x. I haven't > looked at what you have so far but here are some points that > should be considered. > * Monitor timings are something that should be determined between > the driver and the monitor. Users and higher level api's should > not have anything to do with this. The driver I am working on > now has a fixed set of timings that it supports. When set_var > requests a new mode the closest match is found. It is key to > let the driver have it's own mode table. I also will eventually > parse EDID to add modes to my tables is the monitor needs > something special that I can support. To aid in code reuse you > should just provide a function that parses EDID data into an > edid data structure (Something like this was discussed a few > day ago) Most defintely. That was what fbmon.c was for. Unfortunely I never had the time to work on it. Now that 2.5.0 is out I'm going to figure something out. I did see the patch sent out and I'm going to start with that. I just like to make monitor stuff EDID independent. I don't want to be stuck with this api for the next 20 years especially when the technology will change. > * The user api needs to move away from timings all together. > The user should be able to select a refresh rate from a provided > list (negotiated between monitor and driver). It won't be long > before timings are no longer used in hardware, and the only thing > left to adjust will be refresh. > > #2 Complete separation of data structures. The var and fix structures > need rework badly. All things that are not explicitly needed by > a higher level api should not be in there. Those things belong > in the driver private data structures (It doesn't matter that > nearly everyone will have an mmio pointer, it doesn't belong in > a public data structure) First I plan to cleanup the framebuffer layer. Then with the new device filesystems coming up in 2.5.X plan to create a new interface for all this. So the current inteface will go away. I plan to make something like /dev/gfx/card0/frame0/resolution /endian /frame To change the resolution of a framebuffer we can do a cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. As you can see with this new design we have alot more flexiablity. Lots of other nice features but this is down the road. > * The software fallback functions should be set up in a more > explicit way to keep these pointers out of other people's hands. > For example, the console functions (putc, putcs etc) should > be done something like this. > fb->console_ops = create_generic_console_ops(base,pitch,depth); > or use a hardware specific set as you would today. Those will be hidden from the fbdev driver writer. Then will all be managed in fbcon.c. > * I've seen mention of this in some posts but clearly the fb > driver should not be tied in any way to the console. My driver > has all the hardware functions totally independent of the > interface. The fbcon is an interface provided on top of a > graphics driver. They are currently way too connected, and > in my opinion this is one reason that a lot of the X & DRI > developers are not interested in combining efforts. The > result of console + graphics driver looks nothing like a > graphics driver and isn't appealing as a base driver to expand > on. Agree. This will change. Plus the gfx interface I mention above wil be my attempt to combine DRI and fbdev. > #3 Don't try to wrap everything in a hardware independent API. Some > hardware is going to support things that others don't. Take for > instance "mirroring". The i810 can do this on the CRT + a TV or > FP depending on what is connected. But the modes that can be > supported are very limited and mucking up a mode API with this > type of thing only makes a mess for everyone. Better to allow > a hardware specific switch to alter the output device and just > allow the driver to limit the available modes based on this > hardware specific switch. This is what struct fb_info.par is for. It is the hardware dependent structure in struct fb_info. If you have more than one frmaebuffer on the graphics card then you have 2 struct fb_info that share the same par. Now if one attempts to set the graphics mode that both can't support at the same time since they share the same par they will know before hand. That is what fb_check_var is for. > #4 It would certainly be nice to combine the drm code into the fb > code. NOTE: I wouldn't want to do this until the drivers are > organized like graphics drivers instead of consoles. Agree. |
|
From: Petr V. <van...@vc...> - 2001-11-25 02:01:02
|
On Sat, Nov 24, 2001 at 08:52:09AM -0800, James Simmons wrote: > > something special that I can support. To aid in code reuse you > > should just provide a function that parses EDID data into an > > edid data structure (Something like this was discussed a few > > day ago) > > Most defintely. That was what fbmon.c was for. Unfortunely I never had the > time to work on it. Now that 2.5.0 is out I'm going to figure something > out. I did see the patch sent out and I'm going to start with that. I just > like to make monitor stuff EDID independent. I don't want to be stuck with > this api for the next 20 years especially when the technology will change. Are you sure that this is really needed? You are not inventing API for next 20 years. You are inventing API now, for current products. You can change API anytime in future, and API will definitely change, as it already changed in the past. Also EDID is so universal that you can express almost everything using that, and also do not forget that there exist bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and that this bidirectional communication may be required for proper operation (i.e. enabling) of USB/IEEE1394 ports built into monitor. > > * The user api needs to move away from timings all together. > > The user should be able to select a refresh rate from a provided > > list (negotiated between monitor and driver). It won't be long > > before timings are no longer used in hardware, and the only thing > > left to adjust will be refresh. And our monitors will do plop and disappear? We are using 12 years old monitors for some tasks, and we'll not throw them away before they'll physically stop functioning. > /dev/gfx/card0/frame0/resolution > /endian > /frame > > To change the resolution of a framebuffer we can do a > > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. > > As you can see with this new design we have alot more flexiablity. Lots of > other nice features but this is down the road. Yes. For example floating point support in the kernel. I'd like to know how you'll persuade driver to know that '640x480-YUV422@59.94i' should be NTSC 800x525 interlaced picture, and how you'll center picture on screen then? Where do you specify virtual xres and yres? > > graphics driver and isn't appealing as a base driver to expand > > on. > > Agree. This will change. Plus the gfx interface I mention above wil be my > attempt to combine DRI and fbdev. There are drivers which support text modes - and if your new API will not support them... well, you'll have to create another API. > > #3 Don't try to wrap everything in a hardware independent API. Some > > hardware is going to support things that others don't. Take for > > instance "mirroring". The i810 can do this on the CRT + a TV or > > FP depending on what is connected. But the modes that can be > > supported are very limited and mucking up a mode API with this > > This is what struct fb_info.par is for. It is the hardware dependent > structure in struct fb_info. If you have more than one frmaebuffer on the > graphics card then you have 2 struct fb_info that share the same par. Now > if one attempts to set the graphics mode that both can't support at the > same time since they share the same par they will know before hand. That > is what fb_check_var is for. It is something else. You can have two CRTCs (== two /dev/fb*), four outputs (analog VGA #1, analog VGA #2, digital FP #1 and TVOut #1) of which 2 or 3 can be active at one time, and a scaler which can insert third picture into one of outputs... API should at least provide universal way for enumerating device outputs and finding dependencies between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and /dev/fb2 shares memory and outputs with /dev/fb3). Best regards, Petr Vandrovec van...@vc... |
|
From: James S. <jsi...@tr...> - 2001-11-25 05:30:46
|
> Are you sure that this is really needed? You are not inventing API for next > 20 years. You are inventing API now, for current products. You can change > API anytime in future, and API will definitely change, as it already > changed in the past. Also EDID is so universal that you can express > almost everything using that, and also do not forget that there exist > bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and > that this bidirectional communication may be required for proper operation > (i.e. enabling) of USB/IEEE1394 ports built into monitor. As pointed out their should exist a supset that EDID is apart of. I don't want to run into a issues of some platform using something else that works just as well. I like to think functionality. This kind of thinking will go further. > And our monitors will do plop and disappear? We are using 12 years old > monitors for some tasks, and we'll not throw them away before they'll > physically stop functioning. The reality is if you write the drivers correctly you can have drivers that do the timing for you. Yes you would have to supply the data for the monitor attached before. Their exist receipes for this. > Yes. For example floating point support in the kernel. I'd like to know > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be > NTSC 800x525 interlaced picture, and how you'll center picture on screen > then? Where do you specify virtual xres and yres? Don't shot me. Linus has pointed out that ioctls are to go away in 2.5.X. > > Agree. This will change. Plus the gfx interface I mention above wil be my > > attempt to combine DRI and fbdev. > > There are drivers which support text modes - and if your new API will not > support them... well, you'll have to create another API. Wrong. You create another console driver. Take a look at the STI console code for the PARISC platform. A excellent example. Core code which has a fbdev driver on top for graphcis modes and a sticon for using a text mode from the ROM. Using fbdev for text modes is way to much overhead. Using struct consw only is much lighter in weight. The aim here is to remove bloat. Plus the console code will be removed from all low level drivers period. The embedded industry demands it. I know since I work in it. In the console project we have NVIDIA text console driver. For matrox you could have a matroxcon. Very simple and very sweet. > It is something else. You can have two CRTCs (== two /dev/fb*), four > outputs (analog VGA #1, analog VGA #2, digital FP #1 and TVOut #1) of > which 2 or 3 can be active at one time, and a scaler which can insert > third picture into one of outputs... API should at least provide > universal way for enumerating device outputs and finding dependencies > between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and > /dev/fb2 shares memory and outputs with /dev/fb3). The struct xxx_par represents the hardware state. This encompesses the entire board. So you would place everthing in there. struct fb_info represents one framebuffer and its properties. Thats all. Very simple and very clean. |
|
From: Paul M. <le...@Ch...> - 2001-11-25 05:40:35
|
On Sun, Nov 25, 2001 at 02:34:33AM +0100, Petr Vandrovec wrote: > Are you sure that this is really needed? You are not inventing API for ne= xt > 20 years. You are inventing API now, for current products. You can change > API anytime in future, and API will definitely change, as it already > changed in the past. Also EDID is so universal that you can express > almost everything using that, and also do not forget that there exist > bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and > that this bidirectional communication may be required for proper operation > (i.e. enabling) of USB/IEEE1394 ports built into monitor. > =20 VBE DDC is something else to consider as well.. > > /dev/gfx/card0/frame0/resolution > > /endian > > /frame > > =09 > > To change the resolution of a framebuffer we can do a=20 > >=20 > > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. =20 > >=20 > > As you can see with this new design we have alot more flexiablity. Lots= of > > other nice features but this is down the road. >=20 > Yes. For example floating point support in the kernel. I'd like to know= =20 > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be= =20 > NTSC 800x525 interlaced picture, and how you'll center picture on screen > then? Where do you specify virtual xres and yres? > =20 Your overthinking it. For one, as long as modes are in a consistent format, it's easy for anyone to parse. And since people are already used to the "640x480-16@70" style format, what's the big deal? As far as virtual xres and yres.. keep in mind this is a virtual filesystem= .. if your driver or subsystem has additional needs, you can simply register a new entry to deal with virtual resolution.. If you want a place for virtual resolution.. something like: /dev/gfx/card0/frame0/resolution_virt should suffice just fine. (Name pending). Regards, --=20 Paul Mundt <le...@ch...> |
|
From: James S. <jsi...@tr...> - 2001-11-25 06:29:50
|
> > Yes. For example floating point support in the kernel. I'd like to know > > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be > > NTSC 800x525 interlaced picture, and how you'll center picture on screen > > then? Where do you specify virtual xres and yres? > > > Your overthinking it. For one, as long as modes are in a consistent format, > it's easy for anyone to parse. And since people are already used to the > "640x480-16@70" style format, what's the big deal? With modedb it wouldn't be that much of a big step. > As far as virtual xres and yres.. keep in mind this is a virtual filesystem.. > if your driver or subsystem has additional needs, you can simply register a > new entry to deal with virtual resolution.. If you want a place for virtual > resolution.. something like: > > /dev/gfx/card0/frame0/resolution_virt > > should suffice just fine. (Name pending). Okay I see people got confussed over the ASCII thing. Yes Linus wants ioctls to go away. There have been huge ioctl clashes in the past. Plus Linus dreams of a network transparentancy. I also like that idea. So the two things he wants to see go away are mmap and ioctl functionality. In its place you create a file to represent the functionality of the device and that you can read and write data to so its behavior changes. This data can be binary or ASCII. It just has to be passed in via read and write. |
|
From: Petr V. <van...@vc...> - 2001-11-26 02:31:49
|
On Sat, Nov 24, 2001 at 10:29:36PM -0800, James Simmons wrote: > > As far as virtual xres and yres.. keep in mind this is a virtual filesystem.. > > if your driver or subsystem has additional needs, you can simply register a > > new entry to deal with virtual resolution.. If you want a place for virtual > > resolution.. something like: > > > > /dev/gfx/card0/frame0/resolution_virt > > > > should suffice just fine. (Name pending). > > Okay I see people got confussed over the ASCII thing. Yes Linus wants > ioctls to go away. There have been huge ioctl clashes in the past. Plus > Linus dreams of a network transparentancy. I also like that idea. So the > two things he wants to see go away are mmap and ioctl functionality. In > its place you create a file to represent the functionality of the device > and that you can read and write data to so its behavior changes. This data > can be binary or ASCII. It just has to be passed in via read and write. Do not forget that current API is atomic, with doing it in multiple steps you can get nasty surprises (as resolution and resolution_virt depends one on another, either changing one changes also another one, or some modes are not accessible without first modifying resolution_virt), besides not being atomic... And AFAIK Al Viro (main ioctl killer) does not require that every current fb_*_info field should have its own file. From his posts I understand that he is completely satisfied with just some text-based extensible API, so ( echo "mode=1024x768-16@60,outputfmt=NTSC,vxres=2048,xoffset=141" >&0 read a echo $a ) <> /dev/fb0/control' would be enough for him... As there is already couple of comma separated list parsers in the kernel (mount options, kernel cmdline), I think that it is preferred format - in simplest form you write one line in, and get one line back... Best regards, Petr Vandrovec van...@vc... |
|
From: James S. <jsi...@tr...> - 2001-11-27 18:19:34
|
> Do not forget that current API is atomic, with doing it in multiple > steps you can get nasty surprises (as resolution and resolution_virt > depends one on another, either changing one changes also another one, > or some modes are not accessible without first modifying resolution_virt), > besides not being atomic... Not really. If you have a accelerated driver and a userland process open /dev/fb and changes the video mode the driver could be in the middle of a draw operation. So teh fbdev layer lacks any really type of locking. We could add a spinlock or a semaphore but it is more complex then that. The accel engine could be busy for sometime. So we have to wait until it is idle. So a clever way of locking has to be done. > And AFAIK Al Viro (main ioctl killer) does not require that every current > fb_*_info field should have its own file. From his posts I understand > that he is completely satisfied with just some text-based extensible API, > so > ( > echo "mode=1024x768-16@60,outputfmt=NTSC,vxres=2048,xoffset=141" >&0 > read a > echo $a > ) <> /dev/fb0/control' > would be enough for him... As there is already couple of comma separated > list parsers in the kernel (mount options, kernel cmdline), I think that > it is preferred format - in simplest form you write one line in, and > get one line back... Yeap. That is basically what he wants. |
|
From: Geert U. <ge...@li...> - 2001-11-26 10:01:50
|
On Sat, 24 Nov 2001, James Simmons wrote:
> > > Yes. For example floating point support in the kernel. I'd like to know
> > > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be
> > > NTSC 800x525 interlaced picture, and how you'll center picture on screen
> > > then? Where do you specify virtual xres and yres?
> > >
> > Your overthinking it. For one, as long as modes are in a consistent format,
> > it's easy for anyone to parse. And since people are already used to the
> > "640x480-16@70" style format, what's the big deal?
>
> With modedb it wouldn't be that much of a big step.
But then we need to keep the mode database in memory. I think that belongs in
userspace.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X