> > 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.
That is really nice. Setting the values in the color map don't have to
be atomic. Programming the hardware color registers do!! You could do a
loop filling the color map and then do a sync operation that would flush
the values to the hardware. It would be really nice if sysfs files had
hooks for syncing so we could do atomic operations :-)
I realized for the cursor it is the same things. We have several
fields to set but we don't want to program the cursor over and over
again for every slight change. Instead we shoudl cache the changes
until we want to send those changes to the hardware.
-
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/
