[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Questions around adding a monochrome graphics/ascii display driver over gpio framework
# Bill Blass 2008-09-30:
> My goal was to abstract the bus specifics away from the EPSON display
> driver to keep it portable. Specifically, I added the following EPSON
> display driver sources:
> - /usr/src/sys/dev/ic/s1d13700_subr.c
> - /usr/src/sys/dev/ic/s1d13700reg.h
> - /usr/src/sys/dev/ic/s1d13700var.h
> ...and the following gpio source file:
> - /usr/src/sys/dev/gpio/gpiocfag.c
> I added the following content to /usr/src/sys/dev/gpio/files.gpio:
> device gpiocfag: s1d13700, wsemuldisplaydev
> attach gpiocfag at gpio
> file dev/gpio/gpiocfag.c gpiocfag
Looks good if 's1d12700_subc.c' is a trivial piece of code. If it's not,
it would be better to make it a driver on its own and have 'gpiocfag'
as its attachment. Something along the lines of:
file dev/ic/foo.c foo
attach foo at gpio with foo_gpio
file dev/gpio/foo_gpio.c foo_gpio
The idea is that the 'ic' part has all the chip logic and the '<bus>'
part has just enough code to glue the 'real' driver to the underlying
> 2) I do not intend to operate the display as a terminal. I intend to
> operate the display as a status display which will contain a mix of ascii
> and bitmap images.
Sounds neat! :-)
> Ideally, I'd like to see a usermode appliation/service drive the display,
> but I am unsure how the usermode code will interfae with the driver.
> - Should I implement a character or block device or both (one for ascii
> and one for graphics)?
Character device would be fine.
It would be nice to handle the ascii part as a wscons tty and use extra
set of iocttls for the bitmap part, but I don't know if that's reasonably
> - Should the open/read/write ioctl's be handled in the /usr/src/sys/dev/ic/
> or the /usr/src/sys/gpio code?
In the bus-independent part.
Main Index |
Thread Index |