Hi,
I have been looking at your panel driver, and am attaching a 20x4 alphanueric lcd to it. Will start testing it in a few days as and when I get time. Looks like, it is receiving mostly checkpatch and sparse cleanups.
Just wanted your opinion on few things I was thinking:
1) Number of lines you have fixed to 2 and 40 char per line. since I am going to connect 20x4 , i need to remember that after displaying 20 character in 1st line, next char will come to 3rd line. instead why don't we make the option of number of line to 4 ?
2) The lcd commands you are writing to the lcd in an escape sequence while writing to the lcd. Instead of that why don't we use ioctl for lcd commands, and writing to the device will involve only sending data to lcd ?
3) You have given fixed minor number in your code. Any problem if we make it dynamic ?
4) For now I am only attaching a LCD, but I also want to attach a keypad to it. Can you please let me know about the schematic of the keypad connection? I can find out from the code, but I have not yet seen the keypad code.
Waiting in anticipation of your reply.
thanks
sudip
Hi Sudip,
[ CCing Mariusz who's currently cleaning up the driver ]
On Tue, Dec 02, 2014 at 01:32:14PM +0530, Sudip Mukherjee wrote:
> Hi,
> I have been looking at your panel driver, and am attaching a 20x4 alphanueric
> lcd to it. Will start testing it in a few days as and when I get time. Looks
> like, it is receiving mostly checkpatch and sparse cleanups.
yes mostly.
> Just wanted your opinion on few things I was thinking:
> 1) Number of lines you have fixed to 2 and 40 char per line. since I am
> going to connect 20x4 , i need to remember that after displaying 20
> character in 1st line, next char will come to 3rd line. instead why
> don't we make the option of number of line to 4 ?
Feel free to do so. I never had the luck to own a 4-line LCD so this
was never even planned. And yes, I remember something about 4-line LCDs
using tricks such as 2x40 addressing being split into 4x20.
> 2) The lcd commands you are writing to the lcd in an escape sequence
> while writing to the lcd. Instead of that why don't we use ioctl for
> lcd commands, and writing to the device will involve only sending data
> to lcd ?
Because you cannot send that from a script. It's just as if you had to use
an ioctl to clear your terminal, inverse its video or to move its cursor,
it would not be very convenient.
> 3) You have given fixed minor number in your code. Any problem if we
> make it dynamic ?
No objection, but I think we should keep a config option to bind to the
old minor. The rationale behind this is that this driver is mostly used
in embedded systems with a fixed /dev.
> 4) For now I am only attaching a LCD, but I also want to attach a
> keypad to it. Can you please let me know about the schematic of the
> keypad connection? I can find out from the code, but I have not yet
> seen the keypad code.
It used to be documented as an ASCII-art diagram but I can't find that
anymore :-/ IIRC you had to wire buttons between some of the outputs and
some of the inputs. From what I remember, it was possible to detect that
an input is :
- tied to ground
- tied to a data line
- tied to a control line
I found this comment in the old source file :
"document 24 keys keyboard (3 rows of 8 cols, 32 diodes + 2 inputs)"
So maybe we only use data lines and not control lines.
And the keypad code periodically scans all outputs and notes inputs states.
The Nexcom profile works with the keypad, though I don't have the wiring
in mind. It uses 4 keys. It should be easy to find that from the code
though.
Hmmm I found an old description of 2001 (kernel 2.2.18) from the one of the
first circuit I made (with a serial lcd). It involved the smartcard detector
(now removed) and 6 keys :
strobe -> lcd.strobe
d0 -> lcd.serial.din (serial) + lcd.parallel.d0 + keypad.k0
d1 -> d7 => lcd.parallel.d1-d7 + keypad.k1-k7
ack <- smartcard.dout
busy <-
pe <- (keypad common1 if more than 8 keys)
select <- keypad common0
autofeed -> lcd.serial.backlight / lcd.parallel.rs
error <- smartcard.detector
init ->
select_in ->
And here's the module load command I used to run :
insmod /tmp/panel-0.8.0.o parport=0 lcd_enabled=2 keypad_enabled=1 lcd_width=16 lcd_hwidth=16 lcd_height=2
Hoping this helps,
Willy
On Sat, Dec 06, 2014 at 09:41:08AM +0100, Willy Tarreau wrote:
> Hi Sudip,
>
> [ CCing Mariusz who's currently cleaning up the driver ]
>
> On Tue, Dec 02, 2014 at 01:32:14PM +0530, Sudip Mukherjee wrote:
> > Hi,
> > I have been looking at your panel driver, and am attaching a 20x4 alphanueric
> > lcd to it. Will start testing it in a few days as and when I get time. Looks
> > like, it is receiving mostly checkpatch and sparse cleanups.
>
> yes mostly.
>
> > Just wanted your opinion on few things I was thinking:
> > 1) Number of lines you have fixed to 2 and 40 char per line. since I am
> > going to connect 20x4 , i need to remember that after displaying 20
> > character in 1st line, next char will come to 3rd line. instead why
> > don't we make the option of number of line to 4 ?
>
> Feel free to do so. I never had the luck to own a 4-line LCD so this
> was never even planned. And yes, I remember something about 4-line LCDs
> using tricks such as 2x40 addressing being split into 4x20.
well, i work in a company which is in embedded training, so i have access to few hardware, and for this i can have 16x2 and 20x4 lcd, but no serial lcd ... :(
>
> > 2) The lcd commands you are writing to the lcd in an escape sequence
> > while writing to the lcd. Instead of that why don't we use ioctl for
> > lcd commands, and writing to the device will involve only sending data
> > to lcd ?
>
> Because you cannot send that from a script. It's just as if you had to use
> an ioctl to clear your terminal, inverse its video or to move its cursor,
> it would not be very convenient.
yes, ioctl will not be possible from script. but here in India, we will usually use c code for embedded systems, on very rare occassion we will use scripts. and we will be using open(), read(), write(), ioctl() and close() system calls from our projects.
here, we can have both methods in the code. if someone is using escape sequence - that will work, and we can also have the ioctl for the same purpose.
>
> > 3) You have given fixed minor number in your code. Any problem if we
> > make it dynamic ?
>
> No objection, but I think we should keep a config option to bind to the
> old minor. The rationale behind this is that this driver is mostly used
> in embedded systems with a fixed /dev.
ok. but one doubt: won't misc_register create the /dev entry automatically ?
thanks
sudip
>
> > 4) For now I am only attaching a LCD, but I also want to attach a
> > keypad to it. Can you please let me know about the schematic of the
<snip>
> init ->
> select_in ->
>
> And here's the module load command I used to run :
> insmod /tmp/panel-0.8.0.o parport=0 lcd_enabled=2 keypad_enabled=1 lcd_width=16 lcd_hwidth=16 lcd_height=2
>
> Hoping this helps,
> Willy
>
On Sat, Dec 06, 2014 at 03:39:33PM +0530, Sudip Mukherjee wrote:
> > Feel free to do so. I never had the luck to own a 4-line LCD so this
> > was never even planned. And yes, I remember something about 4-line LCDs
> > using tricks such as 2x40 addressing being split into 4x20.
> well, i work in a company which is in embedded training, so i have access to
> few hardware, and for this i can have 16x2 and 20x4 lcd, but no serial lcd
> ... :(
You could find a cheap serial LCD, a ks0074-based one if you need.
I even think they use SPI, which might be what is implemented in
the driver (though I didn't know about SPI by then).
> > > 2) The lcd commands you are writing to the lcd in an escape sequence
> > > while writing to the lcd. Instead of that why don't we use ioctl for
> > > lcd commands, and writing to the device will involve only sending data
> > > to lcd ?
> >
> > Because you cannot send that from a script. It's just as if you had to use
> > an ioctl to clear your terminal, inverse its video or to move its cursor,
> > it would not be very convenient.
> yes, ioctl will not be possible from script. but here in India, we will
> usually use c code for embedded systems, on very rare occassion we will use
> scripts. and we will be using open(), read(), write(), ioctl() and close()
> system calls from our projects.
> here, we can have both methods in the code. if someone is using escape
> sequence - that will work, and we can also have the ioctl for the same
> purpose.
Sure but similarly the C code can easily emit escape chars that will avoid
to complicate the driver.
> > > 3) You have given fixed minor number in your code. Any problem if we
> > > make it dynamic ?
> >
> > No objection, but I think we should keep a config option to bind to the
> > old minor. The rationale behind this is that this driver is mostly used
> > in embedded systems with a fixed /dev.
> ok. but one doubt: won't misc_register create the /dev entry automatically ?
Yes, if devtmpfs or udev or equivalent are used. It's not always the case
on systems with very few devices where everything is known in advance and
nothing needs to be dynamically configured. That said, I think that static
/dev entries will progressively disappear as kernels evolve. Anyway what
I'm saying is just a warning not to break userland API, and typically a
fixed /dev/lcd major+minor is in direct relation with userland API : if it
works now, changing that will break programs relying on this. I don't have
strong opinions in this area since I don't know how many people use this
driver anyway. Maybe it would be best to proceed in two phases :
1) make it possible to use a dynamic entry without removing the option
for the static one, and deprecating it
2) remove the static option
That way, if any user gets any issue it will be easier for him to revert
#2 and report about it, or update his system if possible.
Regards,
Willy
Hi Supid,
On Sat, Dec 06, 2014 at 03:39:33PM +0530, Sudip Mukherjee wrote:
> On Sat, Dec 06, 2014 at 09:41:08AM +0100, Willy Tarreau wrote:
> > Hi Sudip,
> >
> > [ CCing Mariusz who's currently cleaning up the driver ]
> >
> > On Tue, Dec 02, 2014 at 01:32:14PM +0530, Sudip Mukherjee wrote:
> > > Hi,
> > > I have been looking at your panel driver, and am attaching a 20x4 alphanueric
> > > lcd to it. Will start testing it in a few days as and when I get time. Looks
> > > like, it is receiving mostly checkpatch and sparse cleanups.
> >
> > yes mostly.
> >
> > > Just wanted your opinion on few things I was thinking:
> > > 1) Number of lines you have fixed to 2 and 40 char per line. since I am
> > > going to connect 20x4 , i need to remember that after displaying 20
> > > character in 1st line, next char will come to 3rd line. instead why
> > > don't we make the option of number of line to 4 ?
> >
> > Feel free to do so. I never had the luck to own a 4-line LCD so this
> > was never even planned. And yes, I remember something about 4-line LCDs
> > using tricks such as 2x40 addressing being split into 4x20.
> well, i work in a company which is in embedded training, so i have access to few hardware, and for this i can have 16x2 and 20x4 lcd, but no serial lcd ... :(
Setting the height to 4 is not going to make it work properly - due to
the way the display is working internally. I also own one in 4x20 size
and after I get done with the cleaning stuff, I'm going to add proper
support for it.
> >
> > > 2) The lcd commands you are writing to the lcd in an escape sequence
> > > while writing to the lcd. Instead of that why don't we use ioctl for
> > > lcd commands, and writing to the device will involve only sending data
> > > to lcd ?
> >
> > Because you cannot send that from a script. It's just as if you had to use
> > an ioctl to clear your terminal, inverse its video or to move its cursor,
> > it would not be very convenient.
> yes, ioctl will not be possible from script. but here in India, we will usually use c code for embedded systems, on very rare occassion we will use scripts. and we will be using open(), read(), write(), ioctl() and close() system calls from our projects.
> here, we can have both methods in the code. if someone is using escape sequence - that will work, and we can also have the ioctl for the same purpose.
> >
> > > 3) You have given fixed minor number in your code. Any problem if we
> > > make it dynamic ?
> >
> > No objection, but I think we should keep a config option to bind to the
> > old minor. The rationale behind this is that this driver is mostly used
> > in embedded systems with a fixed /dev.
> ok. but one doubt: won't misc_register create the /dev entry automatically ?
>
> thanks
> sudip
> >
> > > 4) For now I am only attaching a LCD, but I also want to attach a
> > > keypad to it. Can you please let me know about the schematic of the
> <snip>
> > init ->
> > select_in ->
> >
> > And here's the module load command I used to run :
> > insmod /tmp/panel-0.8.0.o parport=0 lcd_enabled=2 keypad_enabled=1 lcd_width=16 lcd_hwidth=16 lcd_height=2
> >
> > Hoping this helps,
> > Willy
> >
On Sat, Dec 06, 2014 at 11:28:54AM +0100, Mariusz Gorski wrote:
> Hi Supid,
>
> On Sat, Dec 06, 2014 at 03:39:33PM +0530, Sudip Mukherjee wrote:
> > On Sat, Dec 06, 2014 at 09:41:08AM +0100, Willy Tarreau wrote:
> > > Hi Sudip,
> > >
> > > [ CCing Mariusz who's currently cleaning up the driver ]
> > >
> > > On Tue, Dec 02, 2014 at 01:32:14PM +0530, Sudip Mukherjee wrote:
<snip>
> > > Feel free to do so. I never had the luck to own a 4-line LCD so this
> > > was never even planned. And yes, I remember something about 4-line LCDs
> > > using tricks such as 2x40 addressing being split into 4x20.
> > well, i work in a company which is in embedded training, so i have access to few hardware, and for this i can have 16x2 and 20x4 lcd, but no serial lcd ... :(
>
> Setting the height to 4 is not going to make it work properly - due to
> the way the display is working internally. I also own one in 4x20 size
> and after I get done with the cleaning stuff, I'm going to add proper
> support for it.
ofcourse, just making the height to 4 will not work properly. Height 4 can be there only for user's advantage. but internally we need to monitor if the user is displaying on 3rd or 4th line, then we need to shift that data to the respective position of the 1st and 2nd line to display it properly.
thanks
sudip
>
> > >
> > > > 2) The lcd commands you are writing to the lcd in an escape sequence
> > > > while writing to the lcd. Instead of that why don't we use ioctl for
> > > > lcd commands, and writing to the device will involve only sending data
> > > > to lcd ?
> > >
<snip>
> > > init ->
> > > select_in ->
> > >
> > > And here's the module load command I used to run :
> > > insmod /tmp/panel-0.8.0.o parport=0 lcd_enabled=2 keypad_enabled=1 lcd_width=16 lcd_hwidth=16 lcd_height=2
> > >
> > > Hoping this helps,
> > > Willy
> > >