[lcdproc] [Fwd: [lcdproc] "named pipe" is different from /dev/lcd kernel code. :-)]

[Harald Klein]

David Glaude wrote:
> 
> Hello,
> 

I think davids idea is a nice path to solve the problem.
the driver is a stand alone program which reads from the pipe and
does the necessary stuff to control the hardware.
mtxorb is simply "forwarding" to /dev/ttySx, pp drivers etc can
use appropriate ioctls to control necessary_stuff(tm).

another bonus is lcdd doesnt have to care about the driver, if usb
things happen after starting lcdd who cares.

another question, im not a fan of winblowsyourpcup(c) but does it
support
pipes? but who wants to hook a lcd up to the pc and uses windoofs :)))

cu, hari


> I think there is a missunderstanding. ;-)
> At least I don't understand anymore what you say.
> 
> I have been talking about "named pipe" wich is a user space thing.
> And as a example of this I have use the filename "/dev/xxx"
> that some have maybe translated to "/dev/lcd".
> 
> >/dev/xxx
> > ^
> > | [Standard write on the device]
> > |
> >MO driver
> 
> Above I am talking about the MO driver that write into serial /dev/ttyS0(?).
> This is/might not be working for Parallel LCD (or I2C).
> It is up to the driver code to choose the best way to talk to the physical
> stuff.
> 
> I don't want the /dev/lcd to be a link to a /dev/pplcd?? with kernel code
> doing the trick.
> 
> I want /dev/lcd (or other file not in /dev) to be a NAMED PIPE
>  to a process (driver) doing the job.
> 
> So LCDd is talking to the driver using named pipe.
> http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212619,00.html
> 
> David GLAUDE
> 
> So what do you think about named pipe as a way to talk from LCDd to the
> driver?
> 
> ---
> This message is related to the following sentense.:
> 
> "To do that would involve getting into kernel-space territory."
> 
> "it would be quite tricky to write stuff into /dev/lcd, and then
> route that back out into user-space to then dump it into the appropriate
> device."
> 
> "Please, don't do that. A device is a piece of hardware, the kernel provides
> special access to. We *do* have a device, we do not need another one
> doing almost the same. That *really* *really* belongs to user space!
> (As it is right now)."
> 
> "No, I'd *really* rather not go the /dev/lcd route."
> 
> -----------------------------------------------------------
> To unsubscribe from this list send a blank message to
> lcdproc-unsubscribe@lists.omnipotent.net

-- 
- Never trust a man who can count to 1,023 on his fingers

pub  1024D/A877CBC6 1999-12-28 Harald Klein _linux@chello.at_
sub  4096g/1577CF5F fp = EE17 F2F0 7986 FDC6 F147  B826 3FA1 452A A877
CBC6


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