Greg KH wrote:
>
> But, what about video devices? David and Pat, we talked about this at
> OLS, but Pat kept the paper we drew on, and the beer we were drinking at
> the time has made my memory a bit fuzzy as to all of your requirements
> for the video subsystem. I remember things about frame buffers and
> monitors and other things like that, but nothing specific, sorry. Could
> you outline your needs and I'll see if this proposed structure would
> solve your issues?
>
I'm still not very familiar with sysfs, but this is a possible simplistic
view for the graphics class:
/sys/class/graphics/
|-- fb0
| |-- framebuffer0
| `-- display0
|-- fb1
| |-- framebuffer1
| |-- display1
| '-- display2
|-- fb2
| |-- framebuffer2
| '-- display3
'-- fb3
|-- framebuffer3
'-- display3
graphics is the class
fb0, fb1, etc is the class_device
framebuffer and display are subclasses?
- fb0 is a simple device, one framebuffer attached to one display
- fb1 is one framebuffer with 2 displays (mirrored)
- perhaps, fb2 and fb3 are multi-head, different framebuffers, different displays
but same device
display does not have a driver as they are created by the framebuffer themselves,
is that okay?
How about backlight/lcd drivers? They can stand on their own, but if a framebuffer
driver is loaded, a backlight/lcd driver can be bound to fb.
How about i2c? Under display?
Offtopic:
Main limitation of sysfs concerning video devices is that the one value,
one attribute may not be appropriate. For example, setting xres and yres also
necessitates simultaneous changes in other attributes of the display (pixelclock,
margins, etc). Jon Smirl somewhat made it work by making mode attribute a string
and accept only modes that are present in the driver's private mode database.
Custom timings are not accepted unless the user updates the private mode database
of the driver (has to use an ioctl to do that).
Similarly, pixelformats are problematic. Again, Jon Smirl made this work somehow
by accepting strings. Custom pixelformats are again problematic, and one has
to use the ioctl to set that.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |