linuxconsole-dev

Re: A modest proposal...

[James S. <jsi...@tr...>]

> > There is a limit to 256 event devices. Now you
> > say that is a good number but given 5 input devices it whould take 15
> > times unplugging and plugging them back in before you run out of numbers.
> > So I like to suggest that we keep track of the "free" numbers and grab the
> > lowest one.
> 
> We do this, at least in evdev.

Yes but input.c you just increase it from what I could see.

Re: AMBA Keyboard and Mouse?

[James S. <jsi...@tr...>]

> > Great!!! Want to give this driver a try? I have it attached. You need to
> > have in input core selected
> > 
> > Input core support
> > Keyboard support
> > 
> > As you know keyboard support is to make the input keybaord behave as a
> > PS/2 keyboard so you need pc_keyb.c compiled in. Yes it is not so hot but
> > 2.5.X will fix that once keyboard.c in char will be converted over to be
> > input based. The next thing is to attach the device you need the program
> > attached above, inputattach. Just do for example
> > 
> > inputattach --ps2serkbd /dev/ttySA1 &
> > 
> > Of course pick the correct serial port. 
> 
> Umm, ok, I've looked through it, and I have a couple of questions:
> 
> 1. when the machine fails to boot, how do you use the keyboard sysrq
> functions if you need a userspace program to run to get the keyboard
> working?  Also, think about the ramdisk loading that requires you to
> hit a key _before_ root is even available (you can't).  This is my
> main concern with this approach.

> If a "serial port" is intended to be used for a keyboard, and has a
> PS2 connector attached to it, then I think we should have some way
> of allowing the kernel to automatically initialise it.

Yes we know. That is why the interest in your "universal" serial code. 
Right now the serial drivers are too diverse to have this happen so we
went the safe route, using the line disipline. We need to make it so that
any serial device can be plugged/unplugged from one type of serial port to
another and it will work perfectly. 
 
> 2. we need yet more code to create these "keyboard" serial drivers,
> with associated device nodes that do not currently exist.  (don't
> expect the above to be tested in a short space of time due to this).

More code? If you mean serio.c and serport.c. Well that same code is
reused by many drivers. It ends up saving more and more when you have more
devices. As for keybdev.c. Well that will go away in 2.5.X. It is only a
hack for now to make input devices behave like PS/2 keyboards. The core of
the console code is wrapped around the assumption that you have a PS/2
keyboard. Once the console migrates to the input api this issue will go
away. I assume you mean by associated device nodes /dev/input/eventX. You
don't need to create them. They just provide away to access the keybaord
hardware in a universal way from userland. 

Re: A modest proposal...

[Vojtech P. <vo...@su...>]

On Wed, Jun 27, 2001 at 09:52:46AM -0700, James Simmons wrote:
> 
> > > Howdy.
> > > 
> > > I notice that, at present, several of the handlers (such as evdev)
> > > assign device numbers independantly. Hence, /dev/input/event2 and
> > > /dev/input/mouse2 may not refer to the same device, and (similarly)
> > > may not refer to the device dubbed input2 on initialization.
> > > 
> > > Might it not make for a somewhat more user-friendly world to have
> > > handlers use dev->number for determining the minor number for each
> > > connected device?
> > > 
> > > This would also make a table of connected input devices somewhat more
> > > useful.
> > 
> > Sounds reasonable to start searching for free numbers at the dev->number
> > position. What others think?
> 
>    Is it possible to match them up like that? I was thinking about it and
> to me it seems like a huge task. Unless I miss understood what he
> suggested.

We can't match them completely, but we should be able to make a good
approximation if the user doesn't do too nasty things to the system.

>    One thing I like to bring up about numbering is when you plug and
> unplug devices. At present when you unplug a device and plug it back in
> the device becomes /dev/input/event[n+1]. Where /dev/input/event[n] now
> has no device attached.

Only if it is open. If it is not, it'll become /dev/input/event[n]

> There is a limit to 256 event devices. Now you
> say that is a good number but given 5 input devices it whould take 15
> times unplugging and plugging them back in before you run out of numbers.
> So I like to suggest that we keep track of the "free" numbers and grab the
> lowest one.

We do this, at least in evdev.

> Say you have 5 devices and you unplug device 3 and then plug
> it back it then it should be device 3 again. Not device 6. 

-- 
Vojtech Pavlik
SuSE Labs

Re: Userland event injector

[Ralf A. <ra...@sh...>]

Hello James,


> Your the PS/2 to serial guy. BTW where can you pick up one of these
> devices? I like to order on to show it off at the company.
I made the existing ones on my own. I can send you one handwired
prototype (i have made 2 and don't need them both at the moment. It does
the keyboard conversion only, the mouse part is soldered and wired but the
ATMEL software (for interleaving, mouse alone works too) is not fully
finished yet) for testing. I leave for 3 weeks of conferences and
holiday next Monday, so just drop me a note and i'll send it by air mail.
I benefit a lot from what the linux-console people did, so that's ok.

regards
 ralf

 --
Best regards,
 Ralf Ackermann

Re: Userland event injector

[James S. <jsi...@tr...>]

> > > I like the idea of just inputattaching" to a pty much more too though !
> > > So looking forward to having a look at your code.
> > 
> > Me too. I look forward to Justin's code. Does this mean we can send events
> > from a remote machine?
> 
> That's what I'm doing with my existing code (posted earlier); 

Hum. I thought it was a work around for hotplug as well as for testing to
inject event packets into the input core. I didn't realize you could do it
remotely as well. Actually I just realized you could make these event
occur over the network.  

> Justin's
> should allow it also. (I'm also involving some userland pipes to do
> byteorder adjustments and such, but these shouldn't be necessary in
> most cases).

I see everyone is working for the same thing. I hope everyone can merge
their work together.

Re: Userland event injector

[Charles D. <cd...@mv...>]

On Wed, Jun 27, 2001 at 12:54:51PM -0700, James Simmons wrote:
> > I like the idea of just inputattaching" to a pty much more too though !
> > So looking forward to having a look at your code.
>=20
> Me too. I look forward to Justin's code. Does this mean we can send events
> from a remote machine?

That's what I'm doing with my existing code (posted earlier); Justin's
should allow it also. (I'm also involving some userland pipes to do
byteorder adjustments and such, but these shouldn't be necessary in
most cases).

Re: Userland event injector

[James S. <jsi...@tr...>]

> I did something similar at
> http://www.iptel-now.de/HOWTO/INPUT_DECOMPOSED/input_decomposed.html

Your the PS/2 to serial guy. BTW where can you pick up one of these
devices? I like to order on to show it off at the company.

> It's using a new device though (the same way Alessandro Rubini did in his
> example and the other email this week did. BTW - i was unsure whether
> this approach can handle bytes arriving "byte by byte" and not "on
> block", so i used another "re-assembling" algorithm, the (hardware)
> devices that i use to inject the events do send interleaved anyway).

Ah. I really need to write some docs on input driver writing. We have docs
but they could be better. 

> I like the idea of just inputattaching" to a pty much more too though !
> So looking forward to having a look at your code.

Me too. I look forward to Justin's code. Does this mean we can send events
from a remote machine?

Re: Userland event injector

[Ralf A. <ra...@sh...>]

I did something similar at
http://www.iptel-now.de/HOWTO/INPUT_DECOMPOSED/input_decomposed.html
It's using a new device though (the same way Alessandro Rubini did in his
example and the other email this week did. BTW - i was unsure whether
this approach can handle bytes arriving "byte by byte" and not "on
block", so i used another "re-assembling" algorithm, the (hardware)
devices that i use to inject the events do send interleaved anyway).

I like the idea of just "inputattaching" to a pty much more too though !
So looking forward to having a look at your code.

regards
 ralf

On Wed, 27 Jun 2001, James Simmons wrote:

>
> > On Tue, Jun 26, 2001 at 01:33:05PM +0100, Justin Cormack wrote:
> > > I seem to have lost my version, though I may be able to reconstruct
> > > it quite quickly. I think it was somewhat simpler: essentially it
> > > used inputattach like the serial drivers but just attached to a pty
> > > rather than a serial port. Because of this it appeared just like any
> > > other event driver. The only question was what event masks to set
> > > and so on.  You could happily open multiple devices etc.
> >
> > Nifty.
> >
> > Please do send me a copy should you get it together, and preferably
> > the list as well -- it sounds like the modifications needed to use it
> > over my existing version should be slight, and the benefits
> > significant; I'd be happy to see it (or any such solution) included in
> > the tree.
>
> Please do. I like to see this as well. Sounds pretty cool.
>
>
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>

-- 
--
Best regards,
 Ralf Ackermann

Re: A modest proposal...

[James S. <jsi...@tr...>]

> > Howdy.
> > 
> > I notice that, at present, several of the handlers (such as evdev)
> > assign device numbers independantly. Hence, /dev/input/event2 and
> > /dev/input/mouse2 may not refer to the same device, and (similarly)
> > may not refer to the device dubbed input2 on initialization.
> > 
> > Might it not make for a somewhat more user-friendly world to have
> > handlers use dev->number for determining the minor number for each
> > connected device?
> > 
> > This would also make a table of connected input devices somewhat more
> > useful.
> 
> Sounds reasonable to start searching for free numbers at the dev->number
> position. What others think?

   Is it possible to match them up like that? I was thinking about it and
to me it seems like a huge task. Unless I miss understood what he
suggested.
   One thing I like to bring up about numbering is when you plug and
unplug devices. At present when you unplug a device and plug it back in
the device becomes /dev/input/event[n+1]. Where /dev/input/event[n] now
has no device attached. There is a limit to 256 event devices. Now you
say that is a good number but given 5 input devices it whould take 15
times unplugging and plugging them back in before you run out of numbers.
So I like to suggest that we keep track of the "free" numbers and grab the
lowest one. Say you have 5 devices and you unplug device 3 and then plug
it back it then it should be device 3 again. Not device 6. 

P.S

   My iPAQ input touchscreen driver went into the handhelds tree.
HaHooooo! Once compaq transfers over I hope to see others transfer over.

Re: Userland event injector

[James S. <jsi...@tr...>]

> On Tue, Jun 26, 2001 at 01:33:05PM +0100, Justin Cormack wrote:
> > I seem to have lost my version, though I may be able to reconstruct
> > it quite quickly. I think it was somewhat simpler: essentially it
> > used inputattach like the serial drivers but just attached to a pty
> > rather than a serial port. Because of this it appeared just like any
> > other event driver. The only question was what event masks to set
> > and so on.  You could happily open multiple devices etc.
> 
> Nifty.
> 
> Please do send me a copy should you get it together, and preferably
> the list as well -- it sounds like the modifications needed to use it
> over my existing version should be slight, and the benefits
> significant; I'd be happy to see it (or any such solution) included in
> the tree.

Please do. I like to see this as well. Sounds pretty cool. 

Re: A modest proposal...

[Vojtech P. <vo...@su...>]

On Sun, Jun 24, 2001 at 12:41:45AM -0700, Charles Duffy wrote:
> Howdy.
> 
> I notice that, at present, several of the handlers (such as evdev)
> assign device numbers independantly. Hence, /dev/input/event2 and
> /dev/input/mouse2 may not refer to the same device, and (similarly)
> may not refer to the device dubbed input2 on initialization.
> 
> Might it not make for a somewhat more user-friendly world to have
> handlers use dev->number for determining the minor number for each
> connected device?
> 
> This would also make a table of connected input devices somewhat more
> useful.

Sounds reasonable to start searching for free numbers at the dev->number
position. What others think?

-- 
Vojtech Pavlik
SuSE Labs

Re: event mixer patch

[Vojtech P. <vo...@su...>]

On Mon, Jun 25, 2001 at 06:17:35PM +0300, Matan Ziv-Av wrote:
> On Sun, 24 Jun 2001, Vojtech Pavlik wrote:
> 
> > On Sun, Jun 24, 2001 at 08:26:45AM -0700, James Simmons wrote:
> > >
> > > > simple, really. open(fd,/proc/bus/usb/devices), select(fd). Select will
> > > > stop blocking once the file changes.
> > >
> > > That I got. How do you determine which device got attached ordetected?
> > 
> > You read the file contents, of course. You get a list of attached
> > devices, all with names and vendor/product IDs, possibly more. You
> > compare it to what you've read last time, the difference is devices that
> > connected/disconnected.
> 
> 
> What about non usb devices?
> Conncecting/disconnecting devices should be solved in the input/evdev
> layer, without relying on other subsystems. 

I was suggesting creating /proc/input/devices, working the same way as
the USB one does.

-- 
Vojtech Pavlik
SuSE Labs

Re: Userland event injector

[Charles D. <cd...@mv...>]

On Tue, Jun 26, 2001 at 01:33:05PM +0100, Justin Cormack wrote:
> I seem to have lost my version, though I may be able to reconstruct
> it quite quickly. I think it was somewhat simpler: essentially it
> used inputattach like the serial drivers but just attached to a pty
> rather than a serial port. Because of this it appeared just like any
> other event driver. The only question was what event masks to set
> and so on.  You could happily open multiple devices etc.

Nifty.

Please do send me a copy should you get it together, and preferably
the list as well -- it sounds like the modifications needed to use it
over my existing version should be slight, and the benefits
significant; I'd be happy to see it (or any such solution) included in
the tree.

Re: Userland event injector

[Charles D. <cd...@mv...>]

On Mon, Jun 25, 2001 at 03:23:29PM -0700, James Simmons wrote:
> > Incidentally, I wrote this before noticing the write call inside the
> > cvs version of evdev.c; however, I still use it for two reasons:
> >=20
> > (1) evdev.c's write call is broken.
>=20
> Broken !! How?

<red face>
On using it, I observed lossage -- calls which were fed in but didn't
make their way back out. I thought I found instances of this in which
the filtering done in input.c was not a suitable explanation; however,
I'm unable to reproduce any such situations now, and am thus compelled
to conclude that they don't exist.
</red face>

Re: Userland event injector

[James S. <jsi...@tr...>]

> Incidentally, I wrote this before noticing the write call inside the
> cvs version of evdev.c; however, I still use it for two reasons:
> 
> (1) evdev.c's write call is broken.

Broken !! How?

> (2) this registers its own input device, rather than piggybacking on
>     something else. For my uses, this is a requirement.
>
> The primary manner in which it differs is that it accepts not a full
> struct input_event, but rather a similar structure but without the
> timeval at the front. I'm still not quite sure whether this was a
> correct decision or not, and if someone wants to include this in the
> main distribution after (and only after) the change is made, I'll
> consider it.

Okay. I will give it a try. 

Userland event injector

[Charles D. <cd...@mv...>]

The attached source injects events into the input core from userland.
I'm using it for simulating input events while testing embedded
systems. It Works For Me. It will probably Work For You, but no
promises there. Significant parts of it were written while I was still
figuring out what the hell is/was going on. Hence, there may be a few
obtuse bits (there certainly is at least one major inefficiency).
Pointing them out to me (or cleaning them up) would be appreciated.

Incidentally, I wrote this before noticing the write call inside the
cvs version of evdev.c; however, I still use it for two reasons:

(1) evdev.c's write call is broken.
(2) this registers its own input device, rather than piggybacking on
    something else. For my uses, this is a requirement.

The primary manner in which it differs is that it accepts not a full
struct input_event, but rather a similar structure but without the
timeval at the front. I'm still not quite sure whether this was a
correct decision or not, and if someone wants to include this in the
main distribution after (and only after) the change is made, I'll
consider it.

interface / way to "generate" input events ?

[Ralf A. <ra...@sh...>]

On Fri, 22 Jun 2001, Vojtech Pavlik wrote:

> On Fri, Jun 22, 2001 at 01:41:02PM +0200, Ralf Ackermann wrote:
> > Hello,
> >
> > after reading input.txt in the kernel documentation my question is:
> >  - Is there a way / interface to generate (feed into the kernel)
> >    events into the kernel?
> >    I mean - the opposite to /dev/input/eventX (that can be read) -
> For complete functionality like this you'll need something ala evdev,
> but turned inside out. It hasn't been written yet, though I was planning
> it.

Based on the information/code from Alessandro Rubini
	http://www.linux.it/kerneldocs/input/input.html
i've made a code snippet that lets you feed in keyboard (or other,
e.g. mouse, if you just do minor changes) events via a device /dev/key_in
into the kernel from user space. That makes testing input adapter programs
that can even be network-transparent (e.g. you feed in the input data via
the net) very easy.
	http://www.iptel-now.de/HOWTO/INPUT_DECOMPOSED/input_decomposed.html
There's a small Tcl/Tk program in a subdirectory that shows how it works
and lets you test.

I intend to use this mechanism for the PS/2-via serial input adapter
	http://www.iptel-now.de/HOWTO/PS2SER/ps2ser.html
that interleaves PS/2 keyboard and mouse input via just 1 serial line.
Keyboard input will be fed in this way whereas mouse input (for X only) uses the
a2x mechanism. The receiver program doing this can easily run in user
space now (at least for developing / testing).
I know how to combine the 2 serial outputs from the uCs doing the
PS/2=>serial conversion via just an AND gate and a mutex using 2 uC
input/output lines now - thanks to the wearable list that gave me valuable
hints. Complete schematics/code to be posted soon.

Hopefully the code can be an utility/example explaining how to use the
input layer in a "decomposed way" in general.

regards
 ralf


-- Best regards,
 Ralf Ackermann

Re: event mixer patch

[Matan Ziv-Av <ma...@sv...>]

On Sun, 24 Jun 2001, Vojtech Pavlik wrote:

> On Sun, Jun 24, 2001 at 08:26:45AM -0700, James Simmons wrote:
> >
> > > simple, really. open(fd,/proc/bus/usb/devices), select(fd). Select will
> > > stop blocking once the file changes.
> >
> > That I got. How do you determine which device got attached ordetected?
> 
> You read the file contents, of course. You get a list of attached
> devices, all with names and vendor/product IDs, possibly more. You
> compare it to what you've read last time, the difference is devices that
> connected/disconnected.


What about non usb devices?
Conncecting/disconnecting devices should be solved in the input/evdev
layer, without relying on other subsystems. 

-- 
Matan Ziv-Av.                         ma...@sv...

Re: event mixer patch

[Vojtech P. <vo...@su...>]

On Sun, Jun 24, 2001 at 08:26:45AM -0700, James Simmons wrote:
> 
> > simple, really. open(fd,/proc/bus/usb/devices), select(fd). Select will
> > stop blocking once the file changes.
> 
> That I got. How do you determine which device got attached or detected?

You read the file contents, of course. You get a list of attached
devices, all with names and vendor/product IDs, possibly more. You
compare it to what you've read last time, the difference is devices that
connected/disconnected.

-- 
Vojtech Pavlik
SuSE Labs

Re: event mixer patch

[James S. <jsi...@tr...>]

> simple, really. open(fd,/proc/bus/usb/devices), select(fd). Select will
> stop blocking once the file changes.

That I got. How do you determine which device got attached or detected?

A modest proposal...

[Charles D. <cd...@mv...>]

Howdy.

I notice that, at present, several of the handlers (such as evdev)
assign device numbers independantly. Hence, /dev/input/event2 and
/dev/input/mouse2 may not refer to the same device, and (similarly)
may not refer to the device dubbed input2 on initialization.

Might it not make for a somewhat more user-friendly world to have
handlers use dev->number for determining the minor number for each
connected device?

This would also make a table of connected input devices somewhat more
useful.

arm port

[James S. <jsi...@tr...>]

Hi folks!!!

  	I like to announce that now the ruby tree can work withboth the
linus tree and russell kings arm tree.  Just drop them i, compile and have
fun!!!

Re: event mixer patch

[Vojtech P. <vo...@su...>]

On Fri, Jun 22, 2001 at 01:18:40PM -0700, James Simmons wrote:

> > USB currently handles this with a select() on /proc/bus/usb/devices. I
> > think we could do the same. Actually a /proc/..../input/devices file
> > would be quite useful.
> 
> :-) Do you have example code for the usb system on how to detect this. I
> could really use this for work.

simple, really. open(fd,/proc/bus/usb/devices), select(fd). Select will
stop blocking once the file changes.

-- 
Vojtech Pavlik
SuSE Labs

Re: event mixer patch

[James S. <jsi...@tr...>]

> USB currently handles this with a select() on /proc/bus/usb/devices. I
> think we could do the same. Actually a /proc/..../input/devices file
> would be quite useful.

:-) Do you have example code for the usb system on how to detect this. I
could really use this for work.

Re: Role of close() in struct input_dev

[Vojtech P. <vo...@su...>]

On Tue, Jun 19, 2001 at 11:41:14PM +0200, Johann Deneux wrote:
> On Tue, 19 Jun 2001, James Simmons wrote:
> 
> > 
> > > There are parts of evdev functions called by userland, and other parts
> > > called by other modules. Namely, evdev_disconnect can be called by serio,
> > > for example.
> > > The problem is still there: I would expect
> > > input_open_device/input_close_devise to be called at least the same
> > > number of times (perhaps we should even take care of the order).
> > 
> > Both would be called the same number of time. Well I hope. The order is
> > what matters. 
> 
> After further checks, yes they actually are called the same number of
> times.
> In fact, I realised the driver doesn't really know when a process does an
> open(). Indeed, input_open_device is called only when the first process
> opens the device, and input_close_device when all processes closed it.
> I would however need a function to be called every time a process accesses
> an i-force device.
> Two solutions:
> 
> - I modify the existing input_{open,close}_device
> Frankly, I don't really like the fact that evdev can be kfreed both by
> evdev_disconnect and evdev_connect. Furthermore, the choice is done after

You meant evdev_disconnect and evdev_release, right?

> the value of evdev->exist, whose access is not protected (possible bug if
> the last process releases the device while the device is being
> disconnected, on a smp machine (weird case, though))

Yes, it's most likely not completely SMP safe. It's simple, though - as
long as the device is connetced *or* is opened, we need struct evdev.

> - I add new callbacks to input_dev
> I need to make modifications to this struct, and having two different kind
> of open functions may be confusing. If driver writers need to make a
> distinction between the first open(), and subsequent open(), they can
> handle it themselves.
> 
> Anyway, it seems we have to check evdev->exist before doing anything in
> evdev_{ioctl,read,write...}, I guess this is what caused the oops I got.

Most likely, yes. read() should be fine, though, as it doesn't do
anything with the device.

-- 
Vojtech Pavlik
SuSE Labs