Menu
▾
▴
linux-fbdev-devel
|
From: Benjamin H. <be...@ke...> - 2003-01-10 19:43:13
|
Hi ! When setting a mode on an LCD display that is not exactly the native mode of that display, we can, on some chips, setup a scaler. However, most of the time, we have 2 difference choices for setting up this scaler: It can preserve or not preserve the aspect ratio. A typical example is the titnium powerbook's 1152x768 mode. If I set it to 1024x768, I can get either horizontal scaling (not preserving aspect ratio) or no scaling with black bars on left & right (preserving aspect ratio). While in most case you actually want to preserve the aspect ratio, it would still I beleive make sense to let the user choose it. Could we define one of the reserved fields in fb_var_screeninfo as beeing a "flags" field for such things ? There are a couple of other things that we may want to stuff into such a bitfield later, I'd suggest reserving one 32 bits field for such flags. Ben. -- Benjamin Herrenschmidt <be...@ke...> |
|
From: Antonino D. <ad...@po...> - 2003-01-11 07:08:46
|
On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote: > Hi ! > > When setting a mode on an LCD display that is not exactly the > native mode of that display, we can, on some chips, setup a > scaler. However, most of the time, we have 2 difference choices > for setting up this scaler: It can preserve or not preserve > the aspect ratio. A typical example is the titnium powerbook's 1152x768 > mode. If I set it to 1024x768, I can get either horizontal scaling (not > preserving aspect ratio) or no scaling with black bars on left & right > (preserving aspect ratio). > > While in most case you actually want to preserve the aspect ratio, it > would still I beleive make sense to let the user choose it. > > Could we define one of the reserved fields in fb_var_screeninfo as > beeing a "flags" field for such things ? There are a couple of other > things that we may want to stuff into such a bitfield later, I'd suggest > reserving one 32 bits field for such flags. > I second to this. It's useful to have an extra field in fb_var_screeninfo for drivers to play around. It's like an extension field and its main use is to expose a hardware capability which is uncommon enough to warrant generic support. It's meaning will vary from driver to driver. I also have a couple of things that come to mind (like switching from truecolor to directcolor and vice versa without rebooting). I currently use var->nonstd which is probably not the the right thing to do. Tony |
|
From: Geert U. <ge...@li...> - 2003-01-11 13:31:26
|
On 11 Jan 2003, Antonino Daplas wrote:
> I also have a couple of things that come to mind (like switching from
> truecolor to directcolor and vice versa without rebooting). I currently
> use var->nonstd which is probably not the the right thing to do.
Since directcolor is a superset of truecolor, shouldn't a driver always use
directcolor, if the hardware supports it?
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
|
|
From: Antonino D. <ad...@po...> - 2003-01-11 13:37:47
|
On Sat, 2003-01-11 at 21:29, Geert Uytterhoeven wrote: > On 11 Jan 2003, Antonino Daplas wrote: > > I also have a couple of things that come to mind (like switching from > > truecolor to directcolor and vice versa without rebooting). I currently > > use var->nonstd which is probably not the the right thing to do. > > Since directcolor is a superset of truecolor, shouldn't a driver always use > directcolor, if the hardware supports it? > Some apps don't know how to treat directcolor. DirectFB-0.9.15 is messed up when visual is in directcolor, so I need truecolor here. I submitted a patch to them so it should get fixed with their next release. However, when I go to X, I want it to be in directcolor, for gamma utilities to work Tony |
|
From: Benjamin H. <be...@ke...> - 2003-01-11 09:48:26
|
On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote: > On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote: > I second to this. It's useful to have an extra field in > fb_var_screeninfo for drivers to play around. It's like an extension > field and its main use is to expose a hardware capability which is > uncommon enough to warrant generic support. It's meaning will vary from > driver to driver. I don't fully agree here. While I agree a driver specific field might be useful, I beleive the "flags" field should have defined meaning. > I also have a couple of things that come to mind (like switching from > truecolor to directcolor and vice versa without rebooting). I currently > use var->nonstd which is probably not the the right thing to do. For this too, defined flags would make sense as other driver might want to implement the same capability, in which case we really want all of them to do it the same way. -- Benjamin Herrenschmidt <be...@ke...> |
|
From: Antonino D. <ad...@po...> - 2003-01-11 10:26:25
|
On Sat, 2003-01-11 at 17:47, Benjamin Herrenschmidt wrote: > On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote: > > On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote: > > > I second to this. It's useful to have an extra field in > > fb_var_screeninfo for drivers to play around. It's like an extension > > field and its main use is to expose a hardware capability which is > > uncommon enough to warrant generic support. It's meaning will vary from > > driver to driver. > > I don't fully agree here. While I agree a driver specific field might > be useful, I beleive the "flags" field should have defined meaning. > > > I also have a couple of things that come to mind (like switching from > > truecolor to directcolor and vice versa without rebooting). I currently > > use var->nonstd which is probably not the the right thing to do. > > For this too, defined flags would make sense as other driver might want > to implement the same capability, in which case we really want all of > them to do it the same way. > Well, yes of course, if a particular hardware feature is quite useful and common, then you need something definitive. But what I also want is another field which will serve as a private communication channel between userspace and driver. Adventurous users/testers can use them to turn a unique hardware feature on/off. This is similar to 'Tweak'ing utilities common in MS Windows. Tony |
|
From: Benjamin H. <be...@ke...> - 2003-01-11 11:08:35
|
On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: > > Well, yes of course, if a particular hardware feature is quite useful > and common, then you need something definitive. But what I also want is > another field which will serve as a private communication channel > between userspace and driver. Adventurous users/testers can use them to > turn a unique hardware feature on/off. This is similar to 'Tweak'ing > utilities common in MS Windows. I already do that in some drivers using private ioctl's, though if what you want is really an additional "feature" affecting a mode setting, then it makes sense to fit it into fb_var_screeninfo -- Benjamin Herrenschmidt <be...@ke...> |
|
From: Antonino D. <ad...@po...> - 2003-01-11 11:45:40
|
On Sat, 2003-01-11 at 19:08, Benjamin Herrenschmidt wrote: > On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: > > > > Well, yes of course, if a particular hardware feature is quite useful > > and common, then you need something definitive. But what I also want is > > another field which will serve as a private communication channel > > between userspace and driver. Adventurous users/testers can use them to > > turn a unique hardware feature on/off. This is similar to 'Tweak'ing > > utilities common in MS Windows. > > I already do that in some drivers using private ioctl's, though if > what you want is really an additional "feature" affecting a mode > setting, then it makes sense to fit it into fb_var_screeninfo > If you only need to do is turn something on or off, assigning it an ioctl may be too much. The "feature" can be anything, not just a mode setting. Also, you will have fbdev drivers writing their own ioctls just for these "little" features, and each will need to have its own utility written specifically for the driver. If you have an fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be used for all drivers. One can even collect all possible 'hardware' tweaks and create a general fb tweaks utility just by using fbset. Of course, if the feature requires something more than just turning a switch on and off, then an ioctl is more practical. Tony |
|
From: Benjamin H. <be...@ke...> - 2003-01-11 12:08:56
|
On Sat, 2003-01-11 at 12:35, Antonino Daplas wrote: > If you only need to do is turn something on or off, assigning it an > ioctl may be too much. The "feature" can be anything, not just a mode > setting. Also, you will have fbdev drivers writing their own ioctls just > for these "little" features, and each will need to have its own utility > written specifically for the driver. If you have an > fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be > used for all drivers. One can even collect all possible 'hardware' > tweaks and create a general fb tweaks utility just by using fbset. > > Of course, if the feature requires something more than just turning a > switch on and off, then an ioctl is more practical. Hrm... I think this is going too far for var_screeninfo. However, we do have need for such "tunable" settings, that can be brightness/contrast/backlight kind of stuff, geometry on some i2c-driven monitors (iMacs typically) etc... It may be interesting to think about an API where the fbdev (or the monitor layer, which is something we currently lack that should probably sit on top of fbdev) to expose the available "settings" and have std ioctls to get/set their values. A bit like sound mixer settings work today maybe. For my immediate need, however, I still think turning one of the reserved fields of var_screeninfo into a "mode_flags" would be useful, we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the driver to not bother keeping aspect ratio (the idea here is that keeping aspect ratio is the default, so 0, even if that's nor really working yet in radeonfb or aty128fb). -- Benjamin Herrenschmidt <be...@ke...> |
|
From: Antonino D. <ad...@po...> - 2003-01-11 12:52:41
|
On Sat, 2003-01-11 at 20:08, Benjamin Herrenschmidt wrote: > > For my immediate need, however, I still think turning one of the > reserved fields of var_screeninfo into a "mode_flags" would be useful, > we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the > driver to not bother keeping aspect ratio (the idea here is that keeping > aspect ratio is the default, so 0, even if that's nor really working yet > in radeonfb or aty128fb). > I wasn't contradicting you. A new feature that can be supported by different hardware and is quite useful deserves a unique flag, and I definitely agree with that. I don't to see my desktop flattened top to bottom if I can prevent it. But aside from the above, I also need a field which is interpreted differently from driver to driver, and is so nebulous that it doesn't deserve its own flag. Just something that can be used to poke the hardware from user space without writing a utility each time. Currently, I'm doing this by setting bits in var->nonstd. Tony |
Thanks for helping keep SourceForge clean.
X