For easy hacks, I would suggest a minimal, trivial device driver that
just supports the the FBIO_UPDATE command (and any other command
unique to the hardware). This driver would have to lie in the
board-specific logic or else have an SPI interface passed to it during
initialization. Or maybe a boardctl(BOARDIOC_IOCTL) command.
Thinking a little more: There is a serialization problem with using
these easy hacks. The communication with NX is asynchronous through a
message queue (this supports mult-threaded graphics clients). In order
to synchronize with the NX server, you would need to do nx_synch() which
blocks until the SYNC message is processed. l Then you can safely do the
low level interface.
If you wanted to support a graphics driver interface via NX, that is
okay too. But we would have to do that right, that is, in a
device-independent, platform-independent, general way.
A better functional partitioning would be to have this
hardware-specific functionality implemented inside of the LCD driver,
rather than in some hack character driver or BOARDIOC_IOCTL. There
is, however, no LCD driver interface exposed to the application; the
LCD driver interface is only available to NX. I suppose it would be
possible to add to an ioctl() method to every LCD (or FB) driver and
and nx_ioctl() method to communicate and device-specific commands with
the driver. But that would be a pretty big effort (but a worthwhile
contribution). I would help on that one; the other, simpler ideas are
basically hacks that could give you the functionality you need. A
generic graphics hardware IOCTL command would besystematic and general
and common to all graphics devices.
An implementation of nx_ioctl() would be queued in order in the message
queue and would not need any special synchronization.
Greg
