Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I can't see a way to query how long of cmap the device supports using
the current fbdev ioctls.

I wouldn't even be messing with cmap except for the true/direct color
support and gamma ramps. Don't I need to know how long the cmap is in
order to set the right gamma ramp?

If I set a 256 entry gamma ramp on a card with 1024 entries, will it
still work right? Or do I need to set all 1024 entries?

On 7/28/05, Jon Smirl <[email protected]> wrote:
> On 7/28/05, Geert Uytterhoeven <[email protected]> wrote:
> > On Thu, 28 Jul 2005, Antonino A. Daplas wrote:
> > > Jon Smirl wrote:
> > > > On 7/28/05, Geert Uytterhoeven <[email protected]> wrote:
> > > > > On Wed, 27 Jul 2005, Linux Kernel Mailing List wrote:
> > > >
> > > > There are a couple of ways to fix this.
> > > > 1) Add a check to limit use of the sysfs attributes to 256 entries. If
> > > > you want more you have to use /dev/fb0 and the ioctl. More is an
> > > > uncommon case.
> > > > 2) Switch this to a binary parameter. Now you have to use tools like
> > > > hexdump instead of cat to work with the data. It was nice to be able
> > > > to use cat to see the current map.
> > > >
> > > > Does anyone have preferences for which way to fix it?
> > >
> > > Or...
> > >
> > >  3) Add another file in sysfs which specifies at what index and how many
> > > entries will be read or written from or to the cmap. With this additional
> > > sysfs file, it should be able to handle any reasonable cmap length, but
> > > it will take more than one reading of the color_map file. Another
> > > advantage is that the entire color map need not be read or written if
> > > only one field needs to be changed.
> > >
> > > I've attached a test patch.  Let me know what you think.
> >
> > I like it! ... But, a disadvantages is that it needs to store state between two
> > non-atomic operations. E.g. imagine two processes doing this at the same time.
> 
> Two attributes is a big problem with atomicity. If you want access to
> the full cmap I would switch to a binary attribute or use the existing
> IOCTL.
> 
> Note that you can set the entire map with the new patch, you just
> can't read it. You can store 1-N entries at any base you want.
> 
> >
> > Gr{oetje,eeting}s,
> >
> >                                                 Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
> >
> > 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
> > -
> > 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/
> >
> 
> 
> --
> Jon Smirl
> [email protected]
> 


-- 
Jon Smirl
[email protected]
-
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]
  Powered by Linux