linuxconsole-dev

EVIOCGKEYCODE - can't deduce arguments.

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to finish off my documentation, and it's down to EVIOC[G,S]KEYCODE.

The problem is that I don't think I understand what the arguments are.

EVIOCGKEYCODE takes a int[2], and the first int looks like it should be passed 
in (ie I set int[0] to some value, then call ioctl(fd, EVIOCGKEYCODE, int), 
and then read back the other value in int[1]).

I guess that the first argument is a scancode, and the second is a keycode.

However when I pass in what I think is a reasonable value (as given by 
showkeys -s), I'm getting -EINVAL.

Example: showkey -s gives me 0x39 for a space bar held down. I assumed if I   

codes[0] = 0x39;
if(ioctl(fd, EVIOCGKEYCODE, codes))
    perror("evdev ioctl");
printf("[0]= %d, [1] = %d\n", codes[0], codes[1]);

Then I would get back codes[1] == KEY_SPACE.

However I get
evdev ioctl: Invalid argument
[0]= 57, [1] = 1073784704

Anyone familiar with this? Or can provide a hint?

I guess EVIOCSKEYCODE just assignes the int[1] keycode to the int[0] scancode. 
I can't make that work until I understand the scancodes business more, I 
think.

Brad
- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9oktrW6pHgIdAuOMRAlfVAKCQvVThsCrOlkxIutLH/osW8hOEJgCdFiTJ
5sdLuX+KSl5K9G6P4cq/t4w=
=LfXd
-----END PGP SIGNATURE-----

Re: 'Phys:' field for keyboards (and other input devices)

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 7 Oct 2002 18:07, Vojtech Pavlik wrote:
> On Fri, Sep 27, 2002 at 09:34:31PM +1000, Brad Hards wrote:
> > And it is broken, at least on USB. We're reporting the same on both
> > EVIOCGPHYS and EVIOGUNIQ - the path.
>
> Hmm, It doesn't seem so to me:
<snip>
You were right, of course. I cut'n'pasted my test code, and forgot to change 
the ioctl from EVIOCGPHYS to EVIOCGUNIQ. I feel quite embarressed :-(

> Others usually don't set UNIQ and only set PHYS as they don't have an
> unique identifier.
So a NULL string means "I don't have a unique identifier"?

I can't actually find a HID device that has a serial number. Maybe I need to 
make one...

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9oiQZW6pHgIdAuOMRAmXRAJ9U1FYsiOGBEDcBYkNn8oKew79fAQCdESCn
zorwQsJhKIq5X2t0c8Mr1Tc=
=1hs7
-----END PGP SIGNATURE-----

Re: 'Phys:' field for keyboards (and other input devices)

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

On Fri, Sep 27, 2002 at 09:34:31PM +1000, Brad Hards wrote:

> On Fri, 27 Sep 2002 21:12, Vojtech Pavlik wrote:
> > > If so, then what is EVIOCGUNIQ for?
> >
> > It's an identifier that a device may or may not have, and if there is
> > one, it must be universally (*) unique for this devices bus, vendor and
> > device id. Like USB storage UUID. It may be a serial number. Not that
> > many input devices have it, but the possibility is there.
> >
> > (*) - in whole universe, not just the system. Also it must not ever change.

> So it must be a property of the device, not a property of the system 
> configuration.

Exactly.

> And it is broken, at least on USB. We're reporting the same on both EVIOCGPHYS 
> and EVIOGUNIQ - the path.

Hmm, It doesn't seem so to me:

hid-core sets UNIQ to be

	usb_string(dev, dev->descriptor.iSerialNumber, hid->uniq, 64)

and PHYS to be

	usb_make_path(dev, buf, 64);
        snprintf(hid->phys, 64, "%s/input%d", buf, intf->altsetting[0].bInterfaceNumber);

Others usually don't set UNIQ and only set PHYS as they don't have an
unique identifier.

-- 
Vojtech Pavlik
SuSE Labs

trivial 2.5.40 input patch

[<ke...@st...>]

Here is a very small patch for module license, Config.help and my email
address in drivers/input/keyboard in 2.5.40. Tested the newtonkbd driver
and it is fine.

diff -urN linux-2.5.40-orig/drivers/input/keyboard/Config.help linux-2.5.40/drivers/input/keyboard/Config.help
--- linux-2.5.40-orig/drivers/input/keyboard/Config.help	Tue Oct  1 07:06:27 2002
+++ linux-2.5.40/drivers/input/keyboard/Config.help	Wed Oct  2 16:19:26 2002
@@ -43,7 +43,7 @@
 
   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will be called maple_keyb.o. If you want to compile it as a
+  The module will be called newtonkbd.o. If you want to compile it as a
   module, say M here and read <file:Documentation/modules.txt>.
 
 CONFIG_KEYBOARD_MAPLE  
diff -urN linux-2.5.40-orig/drivers/input/keyboard/maple_keyb.c linux-2.5.40/drivers/input/keyboard/maple_keyb.c
--- linux-2.5.40-orig/drivers/input/keyboard/maple_keyb.c	Tue Oct  1 07:06:29 2002
+++ linux-2.5.40/drivers/input/keyboard/maple_keyb.c	Wed Oct  2 17:00:07 2002
@@ -14,6 +14,7 @@
 
 MODULE_AUTHOR("YAEGASHI Takeshi <t...@ke...>");
 MODULE_DESCRIPTION("SEGA Dreamcast keyboard driver");
+MODULE_LICENSE("GPL");
 
 static unsigned char dc_kbd_keycode[256] = {
 	  0,  0,  0,  0, 30, 48, 46, 32, 18, 33, 34, 35, 23, 36, 37, 38,
diff -urN linux-2.5.40-orig/drivers/input/keyboard/newtonkbd.c linux-2.5.40/drivers/input/keyboard/newtonkbd.c
--- linux-2.5.40-orig/drivers/input/keyboard/newtonkbd.c	Tue Oct  1 07:05:46 2002
+++ linux-2.5.40/drivers/input/keyboard/newtonkbd.c	Wed Oct  2 16:24:37 2002
@@ -1,29 +1,10 @@
 /*
- *  Copyright (c) 2000 Justin Cormack
+ *  Copyright (c) 2000 Justin Cormack <ju...@st...>
  */
 
 /*
- * Newton keyboard driver for Linux
- */
-
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * Should you need to contact me, the author, you can do so either by
- * e-mail - mail your message to <j.c...@do...>, or by paper mail:
- * Justin Cormack, 68 Dartmouth Park Road, London NW5 1SN, UK.
+ * Apple Newton serial keyboard driver for Linux
+ * Also works for compatible serial keyboards eg KeySync
  */
 
 #include <linux/slab.h>
@@ -32,7 +13,9 @@
 #include <linux/init.h>
 #include <linux/serio.h>
 
-MODULE_AUTHOR("Justin Cormack <j.c...@do...>");
+MODULE_AUTHOR("Justin Cormack <ju...@st...>");
+MODULE_DESCRIPTION("Newton keyboard driver");
+MODULE_LICENSE("GPL");
 
 #define NKBD_KEY	0x7f
 #define NKBD_PRESS	0x80

console assignment

[svetljo <sv...@ly...>]

Hi Aivilis
Hi all,

i tried the patch from Aivlis, and i'm getting some strange 
things, i really don't know how to explain them, but maybe someone else had the same troubles.

i was having the same problem when i tried to run 2 X servers on
one Matrox G550 DH AGP with X server patched with the event interface patches from Miguel, both X servers were started but everything was displayed on G550's first head. later on he maid some test with Matrox G450DH and he got it working, even with one accelerated head,
but with my G550 i got it somehow working useing only the X fb driver,
tried to get acceleration on the first head -- both screens appear on the first head.

so
what i think my problem now ist:
somehow the kernel recognize G550 second head and assigns the second keyboard( VT ) to it, 
so if i try to start 2 X servers - G550 1st head and SiS6326 pci
sometimes i get the same screen just like when i tried to run 2 X servers on G550, sometimes the X server on g550 1st head works,
but i can not get the X server on the sis card to start
according to X log files everything should be running, no error messages, but the X server doesn't come up,

if i use sis6326 for primary the monitor looses signal when i try to start X

if i use it as secondary card the monitor never gets signal 

i'll try ASAP with nvidiaTNT2 M64 pci

so my questions would be

can i be right that g550 second head is as signed to the second VT?

in case yes can X try to start on it even if i had specified the SIS6236 pci id, chip ... and even don't report an error?

how are the graphic cards assigned to VT's?

how can i find what's going on?

best regards,

svetljo

hm forgot some maybe useful info:
dmesg, X-confs, xdm/Xservers & /proc
@ http://varna.demon.co.uk/~svetlio/27Sept/



____________________________________________________________
Tired of all the SPAM in your inbox? Switch to LYCOS MAIL PLUS
http://www.mail.lycos.com/brandPage.shtml?pageId=plus

flexible reassignment of input devices

[Andreas S. <an...@sc...>]

I have an obvious, straight forward, well designed and not
working implementation of a userspace agent to assign keyboards
to VTs. 

It is not working because i missunderstood the return value of
the call_userlandhelper() function to return the userland
programms return value. That however is never returned, and I got
convinced that this was so for a good reason: Whenever one waits
for a userland programm to do something for the kernel, one is
vulnerable for DOS attacks. So one tries to NEVER do that and it
is not realistic to expect that anything along this line will
ever make it into the kernel. (yes, module loading is
different... :-)

So if we want to have a userspace configuration/policy agent for
input devices (Greg KH says it is the only way to slove the funky
corner cases of USB devices) we need to take a two level
approach: level one: the kernel assigns any vt to a keyboard at
connection time and notifies userland. level two: Userland makes
an informed decision and signals the kernel to reconfigure
keyboard/vt accordingly. This could happen through a couple of
interfaces: 

- append="" line in lilo.conf. this is not dynamic and tiresome
  to get all the info in that one line.
- /proc filesystem: easy ascii interface, messy, but well
  documented, probatly the way of choice
- ioctl(), binary interface, messy, well documented, second
  choice candidate

and then there are syscalls and a nice filesystem that is only in
2.5.X, while i want this to work on 2.4 with ruby backported.

I would like to get advice on the userland/kernel interface as
well as the kernel internal reconfiguration of keyboards in
regard to their attachment to VTs. Is it enough to
kbd_disconnect() a given keyboard and connect it to an other vt
following the procedure in kbd_connect, or are there any
additional hoops to take?

Re: 'Phys:' field for keyboards (and other input devices)

[Brad M. <bmi...@xm...>]

> Right now i am putting together a system which (among other) uses
> a userspace mechanism to determine the vt which it should bind
> keyboards to. for conveniance i am useing the hotplug interface
> and consider extending hotplug to return vt numbers. 

i wrote an app a while ago that put up "press 0" and "press 1" etc on each head and used the result to map keyboards. (it was in conjunction with a failed attempt to patch the kernel for multihead)

i looked a bit and couldn't find the source, but you get the idea.

one problem is that two usb keyboards would come up in a random order and you'd have to do this at every boot and every time keyboards were plugged/unplugged. not fun. do usb keyboards have a serial number? (dreaming i'm sure)

brad

Re: 'Phys:' field for keyboards (and other input devices)

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 27 Sep 2002 21:12, Vojtech Pavlik wrote:
> > If so, then what is EVIOCGUNIQ for?
>
> It's an identifier that a device may or may not have, and if there is
> one, it must be universally (*) unique for this devices bus, vendor and
> device id. Like USB storage UUID. It may be a serial number. Not that
> many input devices have it, but the possibility is there.
>
> (*) - in whole universe, not just the system. Also it must not ever change.
So it must be a property of the device, not a property of the system 
configuration.

And it is broken, at least on USB. We're reporting the same on both EVIOCGPHYS 
and EVIOGUNIQ - the path.

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9lEJHW6pHgIdAuOMRAntDAKCwPwCAV2+qr1VBfd/M8+hAv5mUYACgp9ei
dIyZET6GrEq0DH0iUqHH1Ls=
=e6Gm
-----END PGP SIGNATURE-----

Re: 'Phys:' field for keyboards (and other input devices)

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

On Fri, Sep 27, 2002 at 08:54:25PM +1000, Brad Hards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 27 Sep 2002 19:10, Vojtech Pavlik wrote:
> > There is a way to determine what event0 is (EVIOCGPHYS), or to find out
> > what a certain mouse has become (/proc/bus/input/devices).
> >
> > As to the device number assignment, it's not sanely possible to do with
> > hotplug, etc. The minor numbers will simply have to stay more or less
> > random.
> Is EVIOCGPHYS unique?

Yes. No two devices in the system can have the same phys: entry

> If not, when wouldn't it be better to use EVIOCGUNIQ instead?
> If so, then what is EVIOCGUNIQ for?

It's an identifier that a device may or may not have, and if there is
one, it must be universally (*) unique for this devices bus, vendor and
device id. Like USB storage UUID. It may be a serial number. Not that
many input devices have it, but the possibility is there.

(*) - in whole universe, not just the system. Also it must not ever change.

-- 
Vojtech Pavlik
SuSE Labs

Re: 'Phys:' field for keyboards (and other input devices)

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 27 Sep 2002 19:10, Vojtech Pavlik wrote:
> There is a way to determine what event0 is (EVIOCGPHYS), or to find out
> what a certain mouse has become (/proc/bus/input/devices).
>
> As to the device number assignment, it's not sanely possible to do with
> hotplug, etc. The minor numbers will simply have to stay more or less
> random.
Is EVIOCGPHYS unique?
If not, when wouldn't it be better to use EVIOCGUNIQ instead?
If so, then what is EVIOCGUNIQ for?

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9lDjhW6pHgIdAuOMRApG3AJ9B5wo5Hvjulp9cefG1Yith9Xkz3QCfUJkZ
DS2lwBVyJygrzb+dUUo4ri4=
=2b0Y
-----END PGP SIGNATURE-----

Re: 'Phys:' field for keyboards (and other input devices)

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

On Fri, Sep 27, 2002 at 10:55:45AM +0200, Andreas Schuldei wrote:

> * Vojtech Pavlik (vo...@su...) [020927 09:54]:
> > > it is important to bind Keyboards to VTs to be able to start
> > > Xservers on that VT. Mice (for X) can be configured in the
> > > XF86Config. but it would perhaps be nice to be able to configure
> > > which mouse goes with which /dev/input/mouse* device, which in
> > > turn get used in the XF86Config. Do people agree on this or is
> > > that unneeded featureism?
> > 
> > No, X should be taught to open the correct /dev/input/event* device (not
> > mouse*), based on a phys (or ID or ...) entry given in XF86Config.
> 
> And that is because the /dev/input/event* is the thing of the
> future and mouse* will pass away? 

Correct.

> But my point was really to have a way to determine/configure
> which mouse would become mouse0 (or even event0, if you please)
> instead of mouse3, etc.

There is a way to determine what event0 is (EVIOCGPHYS), or to find out
what a certain mouse has become (/proc/bus/input/devices).

As to the device number assignment, it's not sanely possible to do with
hotplug, etc. The minor numbers will simply have to stay more or less
random.

> the point in that would be to have 
> - a more tidy XF86Config, where the Xserver :0 connects to the
>   mouse0 etc (this point is minor and rather cosmetic)

If you really need it, you can make a hotplug agent that'll rename or
link or mknod the correct mouse device (based on major/minor) to
/dev/mouse0.

> - a way that a given mouse model remains the dedicated poninting
>   device of a given (configured) Xserver, even after plugging and
>   unplugging of your devices, in which the initialisiation order
>   (and device/event number) might change as of now.
>   This is actually the same as for the keyboards.

This I fear needs to have support in Xserver. For example an userspace
app called by the hotplug agent that'll connect to Xserver and via some
X-extension tell it about what happened to hotpluggable mice.

> Right now i am putting together a system which (among other) uses
> a userspace mechanism to determine the vt which it should bind
> keyboards to. for conveniance i am useing the hotplug interface
> and consider extending hotplug to return vt numbers. 
> 
> I would like to get feedback from someone more involved in these
> matters. who could help me?

Me, Greg KH and Pat Mochel.

-- 
Vojtech Pavlik
SuSE Labs

Re: 'Phys:' field for keyboards (and other input devices)

[Andreas S. <an...@sc...>]

* Vojtech Pavlik (vo...@su...) [020927 09:54]:
> > it is important to bind Keyboards to VTs to be able to start
> > Xservers on that VT. Mice (for X) can be configured in the
> > XF86Config. but it would perhaps be nice to be able to configure
> > which mouse goes with which /dev/input/mouse* device, which in
> > turn get used in the XF86Config. Do people agree on this or is
> > that unneeded featureism?
> 
> No, X should be taught to open the correct /dev/input/event* device (not
> mouse*), based on a phys (or ID or ...) entry given in XF86Config.

And that is because the /dev/input/event* is the thing of the
future and mouse* will pass away? 

But my point was really to have a way to determine/configure
which mouse would become mouse0 (or even event0, if you please)
instead of mouse3, etc.

the point in that would be to have 
- a more tidy XF86Config, where the Xserver :0 connects to the
  mouse0 etc (this point is minor and rather cosmetic)
- a way that a given mouse model remains the dedicated poninting
  device of a given (configured) Xserver, even after plugging and
  unplugging of your devices, in which the initialisiation order
  (and device/event number) might change as of now.
  This is actually the same as for the keyboards.

Right now i am putting together a system which (among other) uses
a userspace mechanism to determine the vt which it should bind
keyboards to. for conveniance i am useing the hotplug interface
and consider extending hotplug to return vt numbers. 

I would like to get feedback from someone more involved in these
matters. who could help me?

Re: 'Phys:' field for keyboards (and other input devices)

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

On Mon, Sep 23, 2002 at 03:38:01PM +0200, Andreas Schuldei wrote:
> I think the dev->phys entry in the input layer is an important
> key to associating a given keyboard with a certain VT (in
> kbd_connect()). 
> 
> I see that for USB keyboards and for ps2 keyboars this field is
> filled in nicely. But are there any other keyboards that are
> valid as controlling keyboards (or in other ways desireable to
> bind to a VT) that do NOT have a valid dev->phys entry?

Everyu input device is required to have a phys entry.

> it is important to bind Keyboards to VTs to be able to start
> Xservers on that VT. Mice (for X) can be configured in the
> XF86Config. but it would perhaps be nice to be able to configure
> which mouse goes with which /dev/input/mouse* device, which in
> turn get used in the XF86Config. Do people agree on this or is
> that unneeded featureism?

No, X should be taught to open the correct /dev/input/event* device (not
mouse*), based on a phys (or ID or ...) entry given in XF86Config.

> Do joysticks need to be bound to
> certain VTs, too? I would not know, I do not even have one. How
> are they accessed?

So far only through /dev/input/js* and /dev/input/event*

-- 
Vojtech Pavlik
SuSE Labs

Re: quickstart guide update

[Andreas S. <an...@sc...>]

* Aivils Stoss (Aiv...@un...) [020924 10:24]:
> >looks like under X you disabled some PCI interaction. what kind of patch
> >would the XFree people want to roll in? would we have an XF86Config
> >option for leaving out those operations?
> This patch is unknow origin. I use it and it work. Can any body in smooth
> english explain this in Xpert mailing list and ask for safe, security.

did this this morning. 
Actually i posted it to patch@x.o:
Your submission to <pa...@xf...> has been assigned the
sequence number 5402.

I did ask for comments, of cause. i will keep you posted.

Re: quickstart guide update

[Aivils S. <Aiv...@un...>]

Hi
>good -- i'm glad you are using the new console work. i have been
>updating the ruby docs (especially the quickstart) and i would like to
>add your comments into what's there.
>
>i see you're patching against 2.4.19. maybe that is why you can't use
>fbdev. do you know if 2.5.x with ruby works for this?
i made backport from ruby CVS. I couldn't start framebuffer under ruby
2.5.X so
will not backport. If James Simons push their work into
linuxconsole.bkbits.com , i can try.

>looks like under X you disabled some PCI interaction. what kind of patch
>would the XFree people want to roll in? would we have an XF86Config
>option for leaving out those operations?
This patch is unknow origin. I use it and it work. Can any body in smooth
english explain this in Xpert mailing list and ask for safe, security.

>i hope things settle down enough to use fbdev with independent multihead
>before too long. i'd be happy with kernel 2.4.x or 2.5.x. we've talked
>about it before... kiosks and public terminals would be an immediate
>win. it would help on hardware costs, but eventually it could help to
>cut maintenance costs too.
i use inna home for entertainment purposes

>* Brad Midgley (bmi...@xm...) [020923 09:09]:
>
>
>>Is it possible to do clean independent multihead? I saw the message from
>>Andreas Schuldei but I don't know if that was similar to Miguel's
>>approach (http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/) or if it is
>>employing the console reorg.
>>
IMHO both X event and console rewrite is good.

Aivils Stoss

Re: quickstart guide update

[Brad M. <bmi...@xm...>]

Andreas

good -- i'm glad you are using the new console work. i have been 
updating the ruby docs (especially the quickstart) and i would like to 
add your comments into what's there.

i see you're patching against 2.4.19. maybe that is why you can't use 
fbdev. do you know if 2.5.x with ruby works for this?

looks like under X you disabled some PCI interaction. what kind of patch 
would the XFree people want to roll in? would we have an XF86Config 
option for leaving out those operations?

i hope things settle down enough to use fbdev with independent multihead 
before too long. i'd be happy with kernel 2.4.x or 2.5.x. we've talked 
about it before... kiosks and public terminals would be an immediate 
win. it would help on hardware costs, but eventually it could help to 
cut maintenance costs too.

brad

>* Brad Midgley (bmi...@xm...) [020923 09:09]:
>  
>
>>Is it possible to do clean independent multihead? I saw the message from 
>>Andreas Schuldei but I don't know if that was similar to Miguel's 
>>approach (http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/) or if it is 
>>employing the console reorg.
>>    
>>
>
>it uses the console work and input seperation. 
>
>Documentation can be found at http://startx.times.lv/, which was
>slightly enhanced as of late.
>
>The kernel configuration documentation needs a rework i feel,
>since the interconnections between the singel configuration
>options is not getting entirely clear yet.
>
>
>I feel that the console reorganisation is a cleaner approach
>to the problem then the one Miguel uses.
>  
>

'Phys:' field for keyboards (and other input devices)

[Andreas S. <an...@sc...>]

I think the dev->phys entry in the input layer is an important
key to associating a given keyboard with a certain VT (in
kbd_connect()). 

I see that for USB keyboards and for ps2 keyboars this field is
filled in nicely. But are there any other keyboards that are
valid as controlling keyboards (or in other ways desireable to
bind to a VT) that do NOT have a valid dev->phys entry?

about binding devices to VTs:

it is important to bind Keyboards to VTs to be able to start
Xservers on that VT. Mice (for X) can be configured in the
XF86Config. but it would perhaps be nice to be able to configure
which mouse goes with which /dev/input/mouse* device, which in
turn get used in the XF86Config. Do people agree on this or is
that unneeded featureism? Do joysticks need to be bound to
certain VTs, too? I would not know, I do not even have one. How
are they accessed?

Re: quickstart guide update

[Andreas S. <an...@sc...>]

* Brad Midgley (bmi...@xm...) [020923 09:09]:
> Is it possible to do clean independent multihead? I saw the message from 
> Andreas Schuldei but I don't know if that was similar to Miguel's 
> approach (http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/) or if it is 
> employing the console reorg.

it uses the console work and input seperation. 

Documentation can be found at http://startx.times.lv/, which was
slightly enhanced as of late.

The kernel configuration documentation needs a rework i feel,
since the interconnections between the singel configuration
options is not getting entirely clear yet.


I feel that the console reorganisation is a cleaner approach
to the problem then the one Miguel uses.

quickstart guide update

[Brad M. <bmi...@xm...>]

Hi,

I've tried to update the quickstart to reflect the current state of 
things, including the kernel config as it stands. I committed the change 
but don't see it at http://linuxconsole.sourceforge.net/quick.html 
[yet]. Will it show up there? Is there a manual copy required before 
things reach the site?

I then tried to follow the instructions using the "supported" kernel 
2.5.27. It won't compile. Should I be using a later kernel? Do we still 
need to apply patches to get the console rework or has it been folded in 
along with the input stuff?

Is it possible to do clean independent multihead? I saw the message from 
Andreas Schuldei but I don't know if that was similar to Miguel's 
approach (http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/) or if it is 
employing the console reorg.

Brad

success...

[Andreas S. <an...@sc...>]

for a few days now i got the dual headed box working and
it seems just fine. 

Even with both people working the box is not to slow or
anything. no apps crashing, DPMS works just fine and
independently on both. This is how i imagined it to work.

And it is much quieter in our working/computer room now. (c:

[BK PATCH] The rest of the handle_sysrq bugs

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

Hi!

  I found more handle_sysrq bugs. I scanned the entire tree and this is it
now.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


ChangeSet@1.546, 2002-09-18 09:28:18-07:00, jsi...@ma...
  More handle_sysrq fixes. That is all of them now.


 arch/um/kernel/um_arch.c     |    2 +-
 drivers/s390/char/ctrlchar.c |    2 +-
 drivers/tc/zs.c              |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)


diff -Nru a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
--- a/arch/um/kernel/um_arch.c	Wed Sep 18 09:39:01 2002
+++ b/arch/um/kernel/um_arch.c	Wed Sep 18 09:39:01 2002
@@ -336,7 +336,7 @@
 		      void *unused2)
 {
 #ifdef CONFIG_SYSRQ
-	handle_sysrq('p', &current->thread.regs, NULL, NULL);
+	handle_sysrq('p', &current->thread.regs, NULL);
 #endif
 	machine_halt();
 	return(0);
diff -Nru a/drivers/s390/char/ctrlchar.c b/drivers/s390/char/ctrlchar.c
--- a/drivers/s390/char/ctrlchar.c	Wed Sep 18 09:39:01 2002
+++ b/drivers/s390/char/ctrlchar.c	Wed Sep 18 09:39:01 2002
@@ -26,7 +26,7 @@

 static void
 ctrlchar_handle_sysrq(struct tty_struct *tty) {
-	handle_sysrq(ctrlchar_sysrq_key, NULL, NULL, tty);
+	handle_sysrq(ctrlchar_sysrq_key, NULL, tty);
 }
 #endif

diff -Nru a/drivers/tc/zs.c b/drivers/tc/zs.c
--- a/drivers/tc/zs.c	Wed Sep 18 09:39:01 2002
+++ b/drivers/tc/zs.c	Wed Sep 18 09:39:01 2002
@@ -443,7 +443,7 @@
 		if (break_pressed && info->line == sercons.index) {
 			if (ch != 0 &&
 			    time_before(jiffies, break_pressed + HZ*5)) {
-				handle_sysrq(ch, regs, NULL, NULL);
+				handle_sysrq(ch, regs, NULL);
 				break_pressed = 0;
 				goto ignore_char;
 			}

===================================================================


This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch24129
M'XL(`"6LB#T``]U674_;,!1]KG^%):2Q:6WB:SM?G8K88-JFL0VQ\8R,8TAI
MFC#;!3KEQ\])*8526M8Q:5M:U6EBGYQ[[SG7V<"'1NENZ\STA\.R,&@#OR^-
M[;:&XNI2Y;FGA+99WB\&7J&LNWM0ENZN/S+:-UKZTJTI<]4Q5ASG"KD)^\+*
M#%\H;;HM\-C-%3L^5]W6P=MWAWNO#Q#J]?!.)HI3]559W.LA6^H+D:=F6[C'
ME85GM2C,4%GAR7)8W4RM*"'4?0*(&`G""D+"HTI""B`XJ)10'H<<3</97AC&
M/%P",7#&`E8Q&L<)VL7@!3S$A/HD\2'&).G2N`MQAT1=0O!R=/R2X0Y!;_#3
MAK2#)/Y4:H7=NC171V9L]'=\TK]2QL/?,F%QWV"1Y[@\P3930UR4EQ[ZB%D8
M`47[LVRCSB\>"!%!T!8^K^NX.)A4]^N*^X8EQ)>9T+ZT.J]//#F++P9"H((D
M"J/J).2IC!BH*$Z(8[@BJ8]X0EW%D,8DJ!A+@IKP\@),$:WT?YC;-"-.(*X`
M"`\JARF(A("ID,@@7E7[Q:`S9B3A$#EF9VE_H+8'0HOQA(S0,O-'0W^@=*%R
M=W947YD!4(AHQ'E%(TJADHJQ])B`C'GH)D2K6*U"G]+C";"P\>9#*VJK/C'Y
M=?%JN@&-&K?2>:^2X)%>!=R!O\:KD_Q_P1U]V7R=]_8?+,4:/MYUSL"`/DR&
MUFUVSS?/-]OXF1QIK0K;V;*95B+UM#HU;?SY<&_OQ:M&&,M\6(OCCS:)WT:O
M?P`JQAF'1CC\_Q#.I./-"6=91M81#VVT0^]+9PH[^7LT4..)9-K8VO&<;JX;
MX^HM?ZWVC%)QH<ZVS<@H+U6+,3AA;@02NVX<D[B1P;V]_M^40;.[/*""ZQRL
L4WCNWH5<Y2=#RQUWJY^U\=TV,7WEDYF2`S,:]ICBJ4NV0C\!T=?@@6\*````
`
end

Re: bitkeeper source for ruby/linuxconsole?

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

On Mon, Sep 16, 2002 at 05:30:56PM +1000, Brad Hards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 16 Sep 2002 17:27, Andreas Schuldei wrote:
> > is there a bitkeeper source where i can pull from to get ruby
> > into my local bitkeeper repository?
> linux-input.bkbits.net ?

That's linux-input only (merged into 2.5 completely anyway). Doesn't
include the console changes from Ruby.

-- 
Vojtech Pavlik
SuSE Labs

[BK patch 1] console changes

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

Hi!

   Since my consoel change is large I'm trying to send you small pieces at
a time. This patch fixes a few drivers that missed the handle_sysrq
changes. Of course you can grab the patch from

bk://linuxconsole.bkbits.net/stable

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


ChangeSet@1.541, 2002-09-17 10:30:14-07:00, jsi...@ma...
  These files missed the handle_sysrq change.


 mips/au1000/common/serial.c |    2 +-
 ppc/4xx_io/serial_sicc.c    |    2 +-
 ppc/8xx_io/uart.c           |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)


diff -Nru a/arch/mips/au1000/common/serial.c b/arch/mips/au1000/common/serial.c
--- a/arch/mips/au1000/common/serial.c	Tue Sep 17 10:53:02 2002
+++ b/arch/mips/au1000/common/serial.c	Tue Sep 17 10:53:02 2002
@@ -433,7 +433,7 @@
 		if (break_pressed && info->line == sercons.index) {
 			if (ch != 0 &&
 			    time_before(jiffies, break_pressed + HZ*5)) {
-				handle_sysrq(ch, regs, NULL, NULL);
+				handle_sysrq(ch, regs, NULL);
 				break_pressed = 0;
 				goto ignore_char;
 			}
diff -Nru a/arch/ppc/4xx_io/serial_sicc.c b/arch/ppc/4xx_io/serial_sicc.c
--- a/arch/ppc/4xx_io/serial_sicc.c	Tue Sep 17 10:53:02 2002
+++ b/arch/ppc/4xx_io/serial_sicc.c	Tue Sep 17 10:53:02 2002
@@ -462,7 +462,7 @@
 #ifdef SUPPORT_SYSRQ
         if (info->sysrq) {
             if (ch && time_before(jiffies, info->sysrq)) {
-                handle_sysrq(ch, regs, NULL, NULL);
+                handle_sysrq(ch, regs, NULL);
                 info->sysrq = 0;
                 goto ignore_char;
             }
diff -Nru a/arch/ppc/8xx_io/uart.c b/arch/ppc/8xx_io/uart.c
--- a/arch/ppc/8xx_io/uart.c	Tue Sep 17 10:53:02 2002
+++ b/arch/ppc/8xx_io/uart.c	Tue Sep 17 10:53:02 2002
@@ -481,7 +481,7 @@
 			if (break_pressed && info->line == sercons.index) {
 				if (ch != 0 && time_before(jiffies,
 							break_pressed + HZ*5)) {
-					handle_sysrq(ch, regs, NULL, NULL);
+					handle_sysrq(ch, regs, NULL);
 					break_pressed = 0;
 					goto ignore_char;
 				} else

===================================================================


This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch17532
M'XL(`/YKAST``]666T_;,!3'G^M/88F73:/).8[M7*9.;#!MT]"&V'A&KF-(
M1M)T<<IERH>?FXX64$L+`FDXD:PFZ;G^_B?9HD?6U$GOE\W+LAI9LD4_5[9)
M>J6ZO#!%X1E5-UF1C\Z\D6G<W<.J<G?]B:U]6VM?N_]4A>G;1@T+0]P#!ZK1
M&3TWM4UZZ`7S*\W5V"2]PX^?CO;?'Q(R&-#=3(U.S0_3T,&`-%5]KHK4[BCG
MKAIY3:U&MC2-\G15MO-'6P;`W"$P#$#(%B7PL-68(BJ.)@7&(\G)=3H[2].X
M:R[&$&7``]Z*&,*`[%'T!$<*S(?8QY`B)`$DR/L0)@#T?NOT34#[0#[0ITUI
MEVCZ,S/6T).\,):6N;4FI4UFJ+.4%N;87MGZ-]6=78]\I9*%D2`'BSJ3_@,7
M(:"`O*/C:0>7IZ%JG?EE/K:^FB``."*FM?$=5;DJ/#W/CH&K<MAB!''8FC12
M*A1#)@(F4..:DF[H9=K'D$DN6P`IT`5^?PLZJ^.Q]J/+R^.\\B?.YXV(,>3`
M1,MX"+(5H%48#&,7L(PW"G>%X1M!,B%X5]U),;$[C>M2Y<U^>-6?0@W=5I\N
MC/&9L5G.QS;7>AXL`DY/UG(9\;@]&:HXY3R-4FD4QL.-XUWM8A&V9"S&3L#K
MNC+5];.C\S0>`A$S;`&!LT[^_);XF4RXW%#\2/OX/XC?\?^=]NN+[G12/EC;
MKD>,AST>2(KDRVSKN74SG%<ZVZ:U.;7;]-O1_O[KMPMJ5L$V0^:Y]?"/&:O*
MH=K49@P<(9!!X`0@HQDEP8NGI-/R,DY6%>-1D$C10=)M],YZ`#"WINGZCX9'
MC_?5>"R;YW,N@,5<=%R@>.E@=*^F55S<JL*C@(AX!T2W]388&]<?D3HS^LQ.
1RH$*4]<I9.0OM'(5R<$*````
`
end

Re: What I should do for official ruby backport?

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

> * Aivils Stoss (Aiv...@un...) [020916 11:35]:
> > Motivation:
> > 1. James Simons will not keep clear code in ruby CVS.

> what I notice is that the interoperation with the rest of the
> kernel is suboptimal. eg: if one activates magic sysrequest keys
> the serial subsytem brakes.

Actually this has been fixed in the latest 2.5.X kernels. I haven't had
the time to back port the fixes into ruby. The plan was to push huge
amount of ruby into 2.5.X then update ruby since I woudn't have much to
do.

> Other general problems are in the area of corner cases: what
> happens if you have more keyboards then vts? So the robustness in
> general is not very high.

If you have more keyboards they are registered but not attached to any
VTs. Once you add a video card then it will attach the keyboard.

> I would encourage you to work together with others (like me :-)
> to improve both your documentation and patch quality. I volunteer
> to go over your webpages and try to straighten out some issues in
> grammar. I could also mirror the site on a box with better
> connectivity or on a debian server.
>
> I have run into several people who would be very interested in
> your setup to work reliably, and once this is packaged and
> it went into debian, i expect that the number of users to
> mulitply.

Really:-) Cool!!!

> i certainly hope you keep up your work. i do not believe this
> goes into mainline 2.4 at anytime, but i think this has the
> potental to become an independent kernel patch, which provides
> something many want in a stable kernel (like alsa for sound?).

True.

Re: What I should do for official ruby backport?

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

> I am not sure what your patch exactly does. But if it's a full ruby
> back-port, I am not sure it is really worth the pain (IMHO). As far as I
> know, ruby is not going to make it into 2.4. It must be quite hard and
> time-comsuming to track the console+input thing, isn't it ?
> Are there many users out there *needing* ruby in 2.4 ? If it's only for
> testing purposes, I guess they can use 2.5.

I agree. That is way I never worked on a 2.4 port. There are just to
many changes to severly subsystem layers to deal with.