[U-Boot-Users] framebuffer drivers without modesetting support?
Hi!
I was wondering if u-boot would also accept the merge of a framebuffer driver that doesn't allow runtime mode-setting.
The reason is not that I'm generally too lazy - but much more the fact that most embedded devices with LCM + LCM controller only support one, maybe a really small number of fixed resolutions.
Wouldn't it be sufficient for the board-level config to specify e.g. a callback function to do the low-level timing configuration of the video controller? This way there could still be a shared framebuffer driver, and any board+fb_driver combination would work. Only the theoretical case of connecting a different display would not be supported... but that doesn't really happen in the handheld embedded device world (think of smartphones, portable media players, navigation devices, ...)
Even inside the Linux kernel e.g. the s3c2410 framebuffer is configured by board-specific platform data.
Also, there are many LCM controller parameters that don't fit into the classical modeline from the CRT world. I'm having a hard time imagining how those parameters should be passed around...
What do you think?
Cheers,
In message 20080706164321.GD20299@prithivi.gnumonks.org you wrote:
I was wondering if u-boot would also accept the merge of a framebuffer driver that doesn't allow runtime mode-setting.
What makes you think that would be a problem?
Even inside the Linux kernel e.g. the s3c2410 framebuffer is configured by board-specific platform data.
And in U-Boot there are some frame buffer drivers that are completely fixed for a specific configuration, too.
What exactly was your problem?
Best regards,
Wolfgang Denk
On Sun, Jul 06, 2008 at 08:47:29PM +0200, Wolfgang Denk wrote:
In message 20080706164321.GD20299@prithivi.gnumonks.org you wrote:
I was wondering if u-boot would also accept the merge of a framebuffer driver that doesn't allow runtime mode-setting.
What makes you think that would be a problem?
That there is no infrastructure (at leaste I've not seen one) for a driver to cleanly indicate that it doesn't support modesetting. So what do we do? Just silently ignore calls to change the video mode?
And in U-Boot there are some frame buffer drivers that are completely fixed for a specific configuration, too.
good.
What exactly was your problem?
I didn't want to submit a driver that doesn't implement the standard/full interface of a framebuffer driver inside u-boot without asking whether that was actually ok.
In message 20080707073037.GB4412@prithivi.gnumonks.org you wrote:
That there is no infrastructure (at leaste I've not seen one) for a driver to cleanly indicate that it doesn't support modesetting. So what do we do? Just silently ignore calls to change the video mode?
There is no such requirement (yet) in U-Boot to implement a full-featured framebufer driver with all the bells and whistles that are needed in Linux.
I didn't want to submit a driver that doesn't implement the standard/full interface of a framebuffer driver inside u-boot without asking whether that was actually ok.
I see. Well, in U-Boot we just have "LCD drivers", and these may or may not implement fancy stuff; usually they don't :-)
Best regards,
Wolfgang Denk
participants (2)
-
Harald Welte -
Wolfgang Denk