sysfs support for framebuffer

sysfs support for framebuffer

[Jon Smirl]

What are the attributes needed for framebuffers in sysfs? 
This is the list I came up with, are there more?

bits_per_pixel - r/w color depth
blank - w set the vesa blank state
color_map - r/w control the color map
console - r/w? map of console number to fb device
cursor - r/w x/y position of the cursor
mode - r/w set the display mode
modes - list of valid modes
pan - r/w x/y of the pan offset
virtual_size - r/w x/y of the virtual size

modes is designed to let a user space root app set the list of valid
modes into the driver
ownership of all other attributes are assigned by pam to the display user
mode must be an entry from the list of modes, this prevents a user
from setting in a damaging mode

The list is based on the current fbdev IOCTLs. All attributes appear
in /sys/class/graphics/fb0/xxxx
Current patch is in the "Patch to add mode setting to sysfs" thread.

fbdev also needs to generate events to let the xserver know if things
have been changed. These can come up through hotplug to dbus.

bits_per_pixel, mode, virtual_size - mode event
blank - blank event
modes - modes event

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: sysfs support for framebuffer

[James Simmons]

> What are the attributes needed for framebuffers in sysfs? 
> This is the list I came up with, are there more?
> 
> bits_per_pixel - r/w color depth
> blank - w set the vesa blank state
> color_map - r/w control the color map
> console - r/w? map of console number to fb device
> cursor - r/w x/y position of the cursor
> mode - r/w set the display mode
> modes - list of valid modes
> pan - r/w x/y of the pan offset
> virtual_size - r/w x/y of the virtual size

Yes. line_length. The cursor needs to be expanded. There is much more than 
that. Pretty much var and fix fields need to be exported to userland.
 
> modes is designed to let a user space root app set the list of valid
> modes into the driver
> ownership of all other attributes are assigned by pam to the display user
> mode must be an entry from the list of modes, this prevents a user
> from setting in a damaging mode
> 
> The list is based on the current fbdev IOCTLs. All attributes appear
> in /sys/class/graphics/fb0/xxxx
> Current patch is in the "Patch to add mode setting to sysfs" thread.

Do we really want everything under fb0. I was thinking we should have a 
directory for a card and under that directory list all the properties. 
I was considering this approach so both DRM and fbdev can exist is the 
same spot. 

cardname0/frame0
	 /mmio0/
	 /zbuffer0/
	 /modes/

We also need to deal with mirroring. How are we going to handle that?
Also some card support chaining cards together to into one monitor. 
We need to really think about the design. Because once it goes into the 
main tree it will be hard to change the userland api. 

> fbdev also needs to generate events to let the xserver know if things
> have been changed. These can come up through hotplug to dbus.
> 
> bits_per_pixel, mode, virtual_size - mode event
> blank - blank event
> modes - modes event

Yeap. 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: sysfs support for framebuffer

[Jon Smirl]

On Mon, 21 Feb 2005 18:50:17 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
> Yes. line_length. The cursor needs to be expanded. There is much more than
> that. Pretty much var and fix fields need to be exported to userland.

I would like to keep the export data to user space at a minimum. So if
you want to set a non-standard mode edit /etc/mode and then use the
root priv app to add it to the list as a binary structure via
sysfs/modes. The patch currently supports this.

> Do we really want everything under fb0. I was thinking we should have a
> directory for a card and under that directory list all the properties.
> I was considering this approach so both DRM and fbdev can exist is the
> same spot.

DRM and fbdev can not exist in the same spot since they make
independent deivces, fb0 and drm0. Udev needs them in two different
places otherwise there is no way to make two 'dev' attributes.

> We also need to deal with mirroring. How are we going to handle that?
> Also some card support chaining cards together to into one monitor.
> We need to really think about the design. Because once it goes into the
> main tree it will be hard to change the userland api.

Mirroring and merged fb would be handled by special modes in the mode
list. You would need ownership of both heads to set these modes.
Setting a mode like this into one head would then disable the device
for the other one.


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: sysfs support for framebuffer

[James Simmons]

> > Yes. line_length. The cursor needs to be expanded. There is much more than
> > that. Pretty much var and fix fields need to be exported to userland.
> 
> I would like to keep the export data to user space at a minimum. So if
> you want to set a non-standard mode edit /etc/mode and then use the
> root priv app to add it to the list as a binary structure via
> sysfs/modes. The patch currently supports this.

If you want to support the same level of functionality as the current 
fbdev setup then you have to export var and fix to userspace. You need 
that data to be able to write to the framebuffer properly. 

> > Do we really want everything under fb0. I was thinking we should have a
> > directory for a card and under that directory list all the properties.
> > I was considering this approach so both DRM and fbdev can exist is the
> > same spot.
> 
> DRM and fbdev can not exist in the same spot since they make
> independent deivces, fb0 and drm0. Udev needs them in two different
> places otherwise there is no way to make two 'dev' attributes.

I mean have drm under /sys/class/graphics/

Also we would have /sys/class/graphics/lcd/
		   /sys/class/graphics/display0/	One for each monitor
		   /sys/class/graphics/zbuffer0/
		   /sys/class/graphics/fb0
etc. 

Now there is a problem to the above. If we have more than one graphics 
card it will get messy. I would guess the X server wants to know what 
things belong to what device. For example the matrox card supports dual 
heads. What if we have 3 graphics cards. Which two fbX devices belong to the 
matrox card. You could scan all the directories and organize a list for 
what belongs to what but that would be messy. Plus what if we plug 
a monitor in. We have to know which things (fb, mmio) effect its output.

> > We also need to deal with mirroring. How are we going to handle that?
> > Also some card support chaining cards together to into one monitor.
> > We need to really think about the design. Because once it goes into the
> > main tree it will be hard to change the userland api.
> 
> Mirroring and merged fb would be handled by special modes in the mode
> list. You would need ownership of both heads to set these modes.
> Setting a mode like this into one head would then disable the device
> for the other one.

Okay. Also for demo mode we don't need to handle every case. Just the 
common ones.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: sysfs support for framebuffer

[Jon Smirl]

On Mon, 21 Feb 2005 21:36:38 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
> Now there is a problem to the above. If we have more than one graphics
> card it will get messy. I would guess the X server wants to know what
> things belong to what device. For example the matrox card supports dual
> heads. What if we have 3 graphics cards. Which two fbX devices belong to the
> matrox card. You could scan all the directories and organize a list for
> what belongs to what but that would be messy. Plus what if we plug
> a monitor in. We have to know which things (fb, mmio) effect its output.

I don't see a problem with the current structure. A two headed card
would show up as fb0 and fb1. The modelist for fb0 and fb1 would both
contain an entry for merged-fb. If you own both devices, then setting
the merged-fb mode will simply disable the other device. Same for
mirroring. If you don't own both devices the shared modes won't be in
the list. Device fb2 would list none of the shared modes. If you
really need to know then both fb0 and fb1 are linked to the same
device node in sysfs.

You are also pointing out a weakness in the fb_info structure. fb_info
is not designed for multiple heads. I can copy it like the matrox case
but this causes a lot of fields that should not be shared to be
copied. A much better design would be to break the structure up into
fb_device and fb_head. Then have an fb_head struct for each head. This
would also reduce the surface area of what fbcon is seeing since it
only needs to see the fb_head structure.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click