staging panel driver

Greg KH greg at kroah.com
Thu Sep 3 20:18:24 UTC 2009


On Thu, Sep 03, 2009 at 09:42:20PM +0200, Peter Hüwe wrote:
> Am Thursday 03 September 2009 20:55:17 schrieb Greg KH:
> > On Thu, Sep 03, 2009 at 08:49:08PM +0200, Peter Huewe wrote:
> > > >
> > > >   while :; do
> > > >      read key
> > > >      case key in
> > > >        'Up') ...
> > > >      ...
> > > >      esac
> > > >      echo "Blah"
> > > >   done </dev/keypad >/dev/lcd
> 
> >
> > Well, if it all can work in userspace using lcdproc, that's great.
> >
> > As long as everyone agrees that's the best way, I'll be glad to drop the
> > driver, just let me know.
> 
> 
> Hmm, 
> I'm not quite sure myself wether the driver is still useful or not.
> The main 'disadvantage' of lcdproc is that you can't use simple shell pipes to 
> write something on the display (afaik), but rather you have to talk to the 
> LCDd (the lcdproc deamon) using sockets or by using telnet.
> So something like echo "test" > /dev/lcd is unfortunately not possible, and 
> you can't write something to it from kernelspace directly.
> 
> Moreover another thing is, even if you really like writing code with sockets 
> (*g*), lcdproc has a rather extensive api [ 
> http://lcdproc.sourceforge.net/docs/current-dev.html#language ]
> The deamon can handle multiple clients, which each can create multiple pages, 
> with different priorities - so it isn't as intuitive as a simple echo "test" 
> > /dev/lcd
> 
> Example session: (I indented lcdproc's responses)
> 
> telnet localhost 13666 
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> hello
> 	connect LCDproc 0.5.2 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8
> client_set -name Example
> 	success
> screen_add myscreen
> 	success
> 	ignore myscreen
> 	listen myscreen
> screen_set myscreen -priority alert
> 	success
> 	listen myscreen
> widget_add myscreen test title
> 	success
> widget_set myscreen test "hello world"
> 	success

I agree it is more complex, but it is a standard and works for all types
of these devices, which is more than this single driver can say :)

I recommend dropping it and just pointing people at lcdproc, as it seems
active and useful.

Is that ok with everyone?

thanks,

greg k-h



More information about the devel mailing list