[lcdproc] Re: devices ?

[Matt]

Joris Robijn mentioned the following:

| I've always like the idea of a kernel module for an LCD on the parralel 
| port like parlcd.o . Mainly because lp.o also exists, and plip.o, that 
| also control the hardware. The serial LCD drivers do not directly 
| control hardware, but leave this to /dev/ttySx. If USB displays also 
| need to be in kernel-space (usblcd.o?), it might be worth considering 
| this after all.

Writing a hd44780 device driver would be acceptable, and I suppose a USB
equivalent would be necessary. The way the parallel port support works in
the kernel is to provide lp.o, plip.o, ppa.o, imm.o etc. to control the
parallel port as they need. Writing a device driver to allow all the
different wired versions to work with the same interface would save some
of the hassles of past. Writing a USB driver to create the same interface
over the USB bus wouldn't be much more difficult, (docs allowing).

Remapping the LCDproc "device" over ttySX would be daft, as the ttySX
devices control the serial devices already using the standard flow control
and such. Ditto for I2C devices which at least under Linux have their own
device files too.

Creating a /dev/lcd symlink to the chosen device has been done up to
0.4pre releases, and would still be fine, if it were not for the fact that
we are planning to support multiple devices under 0.5 and beyond. I think
it would like shoddy to have /dev/lcd0, /dev/lcd1 symlinks all pointing to
device file all over the shop. Maybe something to think about too, is the
impending acceptance of DevFS and such, which in its pure form does not
allow file creation under /dev, devices appear and disappear as and when
their driver is present. Shouldn't we just get used to using /dev/ttyS1,
/dev/i2c-0, etc.? Surely they're not that hard to remember?

Named pipes are also fine, but will only work on a single machine, you
can't provide a network interface without opening a port, and providing
two different interfaces creates more work for whoever. If you didn't
intend to provide network access over 13666, then named pipes wouldn't be
too bad...

Just my 2p

Matt



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net