linuxconsole-dev

Re: Adding User-Space Scancode to Keycode mappings...

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

On Sat, Apr 06, 2002 at 03:28:15PM +0200, Arndt Schoenewald wrote:

> Sorry, I am not up-to-date with regard to the current state of affairs,
> so I can't judge the value of this proposal, but reading this message
> reminded me of a similar problem which I saw when I had a closer look
> at the input system some months ago: It didn't seem to be possible to
> use multiple keyboards with different scancode-to-keycode mappings at
> the same time.

Yes, it is possible now. It was thought about in the design of the code
from the start, the ->keycode array in the struct input_device is
private for each instance of the device and thus can be different.

> Why could this be useful? Well, imagine someone buys a laptop abroad,
> e.g. in the U.S. where you have a broad choice of good and cheap
> products, and wants to use this machine in his home country with a
> local non-U.S. USB desktop keyboard (like a German keyboard where
> e.g. the scan code for "Y" means "Z"). Both keyboards are usable at
> the same time, but only for one the scancode-to-keycode mapping can
> be correct as long as the mapping table is a global system property.

I don't think we'll want to change the Y and Z scancodes, see the USB
HID spec for the reasons.

> Or think of an additional, supplementary input device that also sends
> key events, but has a different scancode mapping, such as the Twiddler2
> from Handykey (http://www.handykey.com/) with its U.S. mapping, but I
> want to use it alongside a German keyboard.
> 
> Is this already supported by the current architecture?

Yes.

-- 
Vojtech Pavlik
SuSE Labs

Re: Adding User-Space Scancode to Keycode mappings...

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

On Sat, Apr 06, 2002 at 02:06:25AM -0500, Thomas H Hendrick wrote:

> I see a problem with the current design of the input interface.  There 
> is a method for layer [3] modules to provide control commands to change 
> the way the handler deals with the device and its events.  This is done 
> through the "fops" pointer in the "input_handler" struct.
> 
> However, there is no method to forward command and control information 
> to the layer [1] module through the input interface.  I believe this is 
> going to present a problem in certain cases, such as with mapping 
> scancodes to keycodes in the layer [1] modules.  If you want to be able 
> to change the keymap, the logical method to do this is with the ioctl 
> interface, but since there is no method to forward the iocrtl to the 
> layer [1] from the layer [3], this is not an option (currently).
> 
> I propose the addition of a member function to the struct input_dev 
> structure, that is a similar format to the ioctl interface, but with the 
> relevant input structures instead of the inode/file pair.  If NULL, this 
> would be ignored.  However, it would be at the option of the device 
> driver writer (layer [3]) to forward any ioctl's to the layer [1] 
> function pointer that it did not understand.
> 
> Now, the downside to this is the layer[1] driver doesn't know anything 
> about files open on the device, so any ioctl changes made to the device 
> would be GLOBAL.  My question(s) are:
> 
> (A) Does this sound like somewhere close to a reasonably architected 
> solution?  It seems like a clean interface to me, since it uses what the 
> kernel already provides, and just makes it available to both providers 
> and not just the handlers.
> 
> (B) What possible reprocussions would something like this have on other 
> subsystems that use the input interface?  What kind of breakage are we 
> looking at?
> 
> Just some thoughts before bedtime.

There isn't an interface to pass IOCTLs through. Yes. That's mainly
because I hoped the layer [1] modules would be separated from userspace
completely, not having to care about how the userspace binding is
implemented (whether via a character device, console, whatever).

Thus the way keyboard scancode to keycode remapping is implemented now -
see EVIOCGKEYCODE and EVIOCSKEYCODE ioctls in evdev.c.

This also may not be the perfect solution, but it seems workable.


-- 
Vojtech Pavlik
SuSE Labs

Re: ruby: Where is USB mouse device file?

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

> >>couldn't we have a similiar interface to the keybds
> >>smth like
> >>/dev/input/keybd0
> >>/dev/input/keybd1
> >>........................
> >>
> >
> >/dev/input/event0,1,2,... is just fine for keyboards.
> >
> but who understands the event protocol,

libSDL, X windows support is in the works. The Jave Virtual machine at
work here uses it :-) 

> i mean X normally does not, are there userspace applications which do
> and i think some of the *BSD's do have /dev/keybd0,1,2 .... or smth similar
> ( i don't remmember the exact name of the keybdev )

Sparc also has a /dev/kbd. Of course none of these kbd interfaces are 
portable. 

Re: [Libff-devel] Sidewinder FF driver

[Fabien B. <fab...@fr...>]

Johann Deneux wrote :
> 
> There really is no reason to be ashamed of dirty code. I don't think any 
> hacker really cares about dirtyness at such early development stages.
> Several people already started to work on this subject, and I believe 
> the amount of code we have seen does not reflect the total amount of 
> time spent on it.
> Furthermore, if you have an heart attack today, what I don't wish you, 
> we lose all your work.
> 

Ok, I didn't have an heart attack, and I put all this stuff on a very
minimal web site: http://madfab.free.fr/ff/index.html

Fabien Brachere

Re: ruby: Where is USB mouse device file?

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

On Wed, Apr 10, 2002 at 11:03:29AM +0200, svetljo wrote:
> >
> >
> >>couldn't we have a similiar interface to the keybds
> >>smth like
> >>/dev/input/keybd0
> >>/dev/input/keybd1
> >>........................
> >>
> >
> >/dev/input/event0,1,2,... is just fine for keyboards.
> >
> but who understands the event protocol,
> i mean X normally does not, are there userspace applications which do
> and i think some of the *BSD's do have /dev/keybd0,1,2 .... or smth similar
> ( i don't remmember the exact name of the keybdev )

And who would understand the keyboard protocol coming from the devices
you propose?

-- 
Vojtech Pavlik
SuSE Labs

Re: ruby: Where is USB mouse device file?

[svetljo <ga...@st...>]

>
>
>>couldn't we have a similiar interface to the keybds
>>smth like
>>/dev/input/keybd0
>>/dev/input/keybd1
>>........................
>>
>
>/dev/input/event0,1,2,... is just fine for keyboards.
>
but who understands the event protocol,
i mean X normally does not, are there userspace applications which do
and i think some of the *BSD's do have /dev/keybd0,1,2 .... or smth similar
( i don't remmember the exact name of the keybdev )

Re: ruby: Where is USB mouse device file?

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

On Wed, Apr 10, 2002 at 10:45:06AM +0200, svetljo wrote:
> just a stupid question
> 
> >>Test:
> >>[root@localhost /]# cat /dev/input/mice
> >>cat: /dev/input/mice: No such device
> >>[root@localhost /]# cat /dev/input/mouse0
> >>cat: /dev/input/mouse0: No such device
> >>[root@localhost /]# cat /dev/input/mouse1
> >>cat: /dev/input/mouse1: No such device
> >>[root@localhost /]# cat /dev/input/mouse2
> >>cat: /dev/input/mouse2: No such device
> >>[root@localhost /]#
> >>
> couldn't we have a similiar interface to the keybds
> smth like
> /dev/input/keybd0
> /dev/input/keybd1
> ........................

/dev/input/event0,1,2,... is just fine for keyboards.

> 
> >Use 'mousedev.c' instead of 'usbmouse.c' Also don't use usbkbd.c, but
> >'keybdev.c'.
> >
> 

-- 
Vojtech Pavlik
SuSE Labs

Re: ruby: Where is USB mouse device file?

[svetljo <ga...@st...>]

just a stupid question

>>Test:
>>[root@localhost /]# cat /dev/input/mice
>>cat: /dev/input/mice: No such device
>>[root@localhost /]# cat /dev/input/mouse0
>>cat: /dev/input/mouse0: No such device
>>[root@localhost /]# cat /dev/input/mouse1
>>cat: /dev/input/mouse1: No such device
>>[root@localhost /]# cat /dev/input/mouse2
>>cat: /dev/input/mouse2: No such device
>>[root@localhost /]#
>>
couldn't we have a similiar interface to the keybds
smth like
/dev/input/keybd0
/dev/input/keybd1
........................

>Use 'mousedev.c' instead of 'usbmouse.c' Also don't use usbkbd.c, but
>'keybdev.c'.
>

Re: ruby: Where is USB mouse device file?

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

On Wed, Apr 10, 2002 at 10:28:39AM +0300, Aivils Stoss wrote:
> Hi
>      I try out USB keyboard and mouse. USB keyboard work very fine as
> secondary.
> I could't find USB mouse device file.
> 
> Files used:
> $Id: hid-core.c,v 1.48 2002/03/10 12:26:40 jdeneux Exp $
> $Id: hid-ff.c,v 1.3 2002/03/10 17:19:57 jdeneux Exp $
> $Id: hid-input.c,v 1.22 2002/03/10 12:26:40 jdeneux Exp $
> $Id: usbkbd.c,v 1.31 2002/01/24 19:51:26 vojtech Exp $
> $Id: usbmouse.c,v 1.17 2002/01/24 19:51:26 vojtech Exp $
> 
> dmesg output
> ...skipped
> Freeing unused kernel memory: 220k freed
> hub.c: USB new device connect on bus1/2, assigned device number 2
> input.c: calling /sbin/hotplug input [HOME=/
> PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/5fe/1/47b
> NAME=Cypress Sem. Cypress USB Mouse]
> input: Cypress Sem. Cypress USB Mouse on usb1:2
> hub.c: USB new device connect on bus1/1, assigned device number 3
> input.c: calling /sbin/hotplug input [HOME=/
> PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/46e/5264/400
> NAME=BTC USB Multimedia Keyboard]
> input: BTC USB Multimedia Keyboard on usb1:1
> input.c: calling /sbin/hotplug input [HOME=/
> PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/46e/5264/400
> NAME=BTC USB Multimedia Keyboard]
> input: BTC USB Multimedia Keyboard on usb1:1
> 
> Test:
> [root@localhost /]# cat /dev/input/mice
> cat: /dev/input/mice: No such device
> [root@localhost /]# cat /dev/input/mouse0
> cat: /dev/input/mouse0: No such device
> [root@localhost /]# cat /dev/input/mouse1
> cat: /dev/input/mouse1: No such device
> [root@localhost /]# cat /dev/input/mouse2
> cat: /dev/input/mouse2: No such device
> [root@localhost /]#
> 
> 
> So, I don't know what's wrong.

Use 'mousedev.c' instead of 'usbmouse.c' Also don't use usbkbd.c, but
'keybdev.c'.

-- 
Vojtech Pavlik
SuSE Labs

Re: ruby: Where is USB mouse device file?

[Johann D. <jo...@do...>]

Aivils Stoss wrote:
> Hi
>      I try out USB keyboard and mouse. USB keyboard work very fine as
> secondary.
> I could't find USB mouse device file.You need to have mousedev loaded to access /dev/input/mice.

-- 
Johann Deneux

ruby: Where is USB mouse device file?

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

Hi
     I try out USB keyboard and mouse. USB keyboard work very fine as
secondary.
I could't find USB mouse device file.

Files used:
$Id: hid-core.c,v 1.48 2002/03/10 12:26:40 jdeneux Exp $
$Id: hid-ff.c,v 1.3 2002/03/10 17:19:57 jdeneux Exp $
$Id: hid-input.c,v 1.22 2002/03/10 12:26:40 jdeneux Exp $
$Id: usbkbd.c,v 1.31 2002/01/24 19:51:26 vojtech Exp $
$Id: usbmouse.c,v 1.17 2002/01/24 19:51:26 vojtech Exp $

dmesg output
...skipped
Freeing unused kernel memory: 220k freed
hub.c: USB new device connect on bus1/2, assigned device number 2
input.c: calling /sbin/hotplug input [HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/5fe/1/47b
NAME=Cypress Sem. Cypress USB Mouse]
input: Cypress Sem. Cypress USB Mouse on usb1:2
hub.c: USB new device connect on bus1/1, assigned device number 3
input.c: calling /sbin/hotplug input [HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/46e/5264/400
NAME=BTC USB Multimedia Keyboard]
input: BTC USB Multimedia Keyboard on usb1:1
input.c: calling /sbin/hotplug input [HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PRODUCT=3/46e/5264/400
NAME=BTC USB Multimedia Keyboard]
input: BTC USB Multimedia Keyboard on usb1:1

Test:
[root@localhost /]# cat /dev/input/mice
cat: /dev/input/mice: No such device
[root@localhost /]# cat /dev/input/mouse0
cat: /dev/input/mouse0: No such device
[root@localhost /]# cat /dev/input/mouse1
cat: /dev/input/mouse1: No such device
[root@localhost /]# cat /dev/input/mouse2
cat: /dev/input/mouse2: No such device
[root@localhost /]#


So, I don't know what's wrong.

Aivils Stoss

Re: [Libff-devel] Sidewinder FF driver

[Johann D. <jo...@do...>]

Fabien Brachere wrote:
> Hello,

Hi,

> I'm new to the list, and I'm working on a Microsoft Sidewinder Force
> Feedback 2 driver (Product ID=0x001b, Vendor ID=0x045e).
> I started to study USB, HID and PID protocols and the joystick seems to
> follow PID specification.
> I implemented a skeleton driver (with latest development kernel 2.5.7)
> which do the following things:
> when insmod'ed : reset device, adjust gain, upload an arbitrary effect
> (sort of machine-gun effect sniffed from the Windows test of the
> joystick) and play it, and it works !
> when rmmod'ed : stop effect, reset device.

That sounds really interesting.

> For the moment, no IOCTL and no relation with evdev except for position
> of joystick and buttons.
> 
> The theory of operations:
> the driver uses 4 flow of data with the device: control in (for "block
> load report" and "pid pool report": see pid spec.), control out (for
> "create new effect report") , interrupt in (for joystick state (axes,
> buttons, power, optical switch)) and interrupt out for all other
> commands (set effect report, set envelope report, device gain report,
> pid device control , ....)
> 
> I've not release yet any file, because it's in early alpha stage and
> it's very dirty code, must clean up before all, implement correct data
> structures to follow PID spec...

There really is no reason to be ashamed of dirty code. I don't think any 
hacker really cares about dirtyness at such early development stages.
Several people already started to work on this subject, and I believe 
the amount of code we have seen does not reflect the total amount of 
time spent on it.
Furthermore, if you have an heart attack today, what I don't wish you, 
we lose all your work.

> I think in a few weeks (depend on the time I have), I put all of that on
> a Web site.
> 
> I've a problem with this driver: I can't insert it without rmmod hid, I
> think it's the fault of hid-input who register the device, so I can't
> register it twice. Any idea ? (without modify hid code).
> 

This is how I did for the Logitech WingMan Cordless Rumble Pad: I 
slightly modified hid.h, hid-core.c and hid-input.c to add new function 
entries.
Then I added a file called hid-ff.c where the code for force feedback 
goes. It's available in linuxconsole's CVS on sourceforge. I designed 
the framework so that other protocols could be added.
Please have a look. If you like the way it's done, please use the existing
framework. If you don't, please explain why so that we can improve it ;)

By the way, I think we should have discussions about drivers on the 
linuxconsole mailing list, and discussions about the userland force 
feedback library on libff-devel.

-- 
Johann Deneux

Possible Interface Shortcoming with input.h/input.c

[Thomas H H. <wy...@at...>]

I've noticed while looking over the code for input.h and input.c, that there
seems to be no method for performing control commands (ioctl's for example) from
the user-side of things on the device-provider, only the device-handler.

The user can use ioctl on the general event device [/dev/input/eventXX]
(evdev.o) to perform some general things, such as change the keymap and get the
version number of the evdev driver.  However, some modules might benefit from a
layered mechanism for ioctl to get down to the device-side of things through the
input layer.  I don't know which, however.

In a nutshell:
to "struct input_dev" in input.h:
+ int (*ioctl)(struct input_dev *dev, struct file* file, unsigned int cmd,
unsigned long arg );

and export in input.c:
+ int input_dev_ioctl( struct input_dev *dev, struct file *file, unsigned int
cmd, unsigned long arg );

This is an interface change, I realize.  Mostly this is up for discussion, and
is not really a proposal, per se.

Now, what would this buy us?  The user could send ioctl commands to the device
provider as well as the device-handler.  However, the question is, is there
anything in the device provider that the user needs to access and control that
we can't already?  The only thing that comes to mind is "Get Low-Level Driver
Version" which is TOTALLY not worth adding interface changes for.  However, if
anyone else can think of other device providers that could benefit from this, it
might be a useful change.

At the very least, I'd like to hear people's thoughts on it.

Now, the immediate problem of loading the keymap from user space already solved,
since the input_dev->keymap pointer points to the low-level keymap array.  We
just need a util from user-space to spend a lot of time chewing some ioctl's.  I
may, however, add an IOCTL symbol to evdev.c to transfer them in bulk, (or at
least more than one key per syscall).  I can take care of the user-space util
pretty easily.  I'm not sure, however, if we can detect the keyboards in atkbd.c
in order to provide the correct keymap for the keyboard being used
automagically.

input_dev->idbus = BUS_I8042;
input_dev->idvendor = 0x0001;        /* Not useful */
input_dev->idproduct = atkbd->set;    /* This tells us if it is extend(set 4),
set 3 or set 2 */
input_dev->idversion = atkbd->id;        /* This is the id reported by the port,
and is 0xab83 for most */

You'd think the user would know what keyboard they were using, and could load it
themselves, unless of course, their keyboard doesn't work natively /without/
loading the keyboard.

Anyways, just some thoughts before I head to the grocery store.  ;)

    --Tom.

Re: Adding User-Space Scancode to Keycode mappings...

[Arndt S. <ab...@sr...>]

On Sat, Apr 06, 2002 at 02:06:25AM -0500, Thomas H Hendrick wrote:
> I've taken a look through the input code for the keyboard devices.  It 
> appears we have modules that fall into three different categories:
> 
> [1] Input Device Providers - these are mostly 
> /ruby/linux/drivers/input/keyboard/*.c
> 
> These provide devices to the input driver, and use the 
> input_register_device functions.
> 
> [2] The Input Module itself.  This is the layer between 1 and 3.
> 
> [3] Input Device Handlers - this is /ruby/linux/drivers/input/keybdev.c, 
> and to some extent, evdev.c as well.  These modules call the 
> input_register_handler functions.
> 
> 
> I see a problem with the current design of the input interface.  There 
> is a method for layer [3] modules to provide control commands to change 
> the way the handler deals with the device and its events.  This is done 
> through the "fops" pointer in the "input_handler" struct.
> 
> However, there is no method to forward command and control information 
> to the layer [1] module through the input interface.  I believe this is 
> going to present a problem in certain cases, such as with mapping 
> scancodes to keycodes in the layer [1] modules.  If you want to be able 
> to change the keymap, the logical method to do this is with the ioctl 
> interface, but since there is no method to forward the iocrtl to the 
> layer [1] from the layer [3], this is not an option (currently).
> [...]

Sorry, I am not up-to-date with regard to the current state of affairs,
so I can't judge the value of this proposal, but reading this message
reminded me of a similar problem which I saw when I had a closer look
at the input system some months ago: It didn't seem to be possible to
use multiple keyboards with different scancode-to-keycode mappings at
the same time.

Why could this be useful? Well, imagine someone buys a laptop abroad,
e.g. in the U.S. where you have a broad choice of good and cheap
products, and wants to use this machine in his home country with a
local non-U.S. USB desktop keyboard (like a German keyboard where
e.g. the scan code for "Y" means "Z"). Both keyboards are usable at
the same time, but only for one the scancode-to-keycode mapping can
be correct as long as the mapping table is a global system property.

Or think of an additional, supplementary input device that also sends
key events, but has a different scancode mapping, such as the Twiddler2
from Handykey (http://www.handykey.com/) with its U.S. mapping, but I
want to use it alongside a German keyboard.

Is this already supported by the current architecture?

Arndt

-- 
Arndt Schoenewald <ab...@sr...>, Software Developer

Adding User-Space Scancode to Keycode mappings...

[Thomas H H. <wy...@at...>]

I've taken a look through the input code for the keyboard devices.  It 
appears we have modules that fall into three different categories:

[1] Input Device Providers - these are mostly 
/ruby/linux/drivers/input/keyboard/*.c

These provide devices to the input driver, and use the 
input_register_device functions.

[2] The Input Module itself.  This is the layer between 1 and 3.

[3] Input Device Handlers - this is /ruby/linux/drivers/input/keybdev.c, 
and to some extent, evdev.c as well.  These modules call the 
input_register_handler functions.


I see a problem with the current design of the input interface.  There 
is a method for layer [3] modules to provide control commands to change 
the way the handler deals with the device and its events.  This is done 
through the "fops" pointer in the "input_handler" struct.

However, there is no method to forward command and control information 
to the layer [1] module through the input interface.  I believe this is 
going to present a problem in certain cases, such as with mapping 
scancodes to keycodes in the layer [1] modules.  If you want to be able 
to change the keymap, the logical method to do this is with the ioctl 
interface, but since there is no method to forward the iocrtl to the 
layer [1] from the layer [3], this is not an option (currently).

I propose the addition of a member function to the struct input_dev 
structure, that is a similar format to the ioctl interface, but with the 
relevant input structures instead of the inode/file pair.  If NULL, this 
would be ignored.  However, it would be at the option of the device 
driver writer (layer [3]) to forward any ioctl's to the layer [1] 
function pointer that it did not understand.

Now, the downside to this is the layer[1] driver doesn't know anything 
about files open on the device, so any ioctl changes made to the device 
would be GLOBAL.  My question(s) are:

(A) Does this sound like somewhere close to a reasonably architected 
solution?  It seems like a clean interface to me, since it uses what the 
kernel already provides, and just makes it available to both providers 
and not just the handlers.

(B) What possible reprocussions would something like this have on other 
subsystems that use the input interface?  What kind of breakage are we 
looking at?

Just some thoughts before bedtime.

Happy Hacking.
--Tom

Re: [Linux-fbdev-devel] [PATCH] new fbdev api

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

> On Fri, 29 Mar 2002, James Simmons wrote:
> >   Please try out this patch. It is port of all the fbdev work that has
> > been done in the dave jones tree to Linus's tree. The patch is way to big
> > (2 Megs) to post so here is the link. It is again 2.5.7. Have fun!!
> > 
> > http://www.transvirtual.com/~jsimmons/new_fbdev.diff
> 
> Perhaps you want to provide a [gb]zipped version as well? I have cable, but not
> everyone has broadband access.

Done! A gzip version is there as well.

Re: [Linux-fbdev-devel] [PATCH] new fbdev api

[Geert U. <ge...@li...>]

On Fri, 29 Mar 2002, James Simmons wrote:
>   Please try out this patch. It is port of all the fbdev work that has
> been done in the dave jones tree to Linus's tree. The patch is way to big
> (2 Megs) to post so here is the link. It is again 2.5.7. Have fun!!
> 
> http://www.transvirtual.com/~jsimmons/new_fbdev.diff

Perhaps you want to provide a [gb]zipped version as well? I have cable, but not
everyone has broadband access.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH] new fbdev api

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

Hi!

  Please try out this patch. It is port of all the fbdev work that has
been done in the dave jones tree to Linus's tree. The patch is way to big
(2 Megs) to post so here is the link. It is again 2.5.7. Have fun!!

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

http://www.transvirtual.com/~jsimmons/new_fbdev.diff

Re: ruby possible bugs

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

> It looks as:
> linux-dj vgacon.c
> for(i=3D0; i<MAX_NR_CONSOLES; i++) {
>  =A0 =A0 =A0 =A0struct vc_data *c =3D vt_cons->vc_cons[i];

This is right for dj tree.=20

> ruby   keyboard.c
> /* enable receieving key events for each VC */
> for (i =3D 0; i < MAX_NR_USER_CONSOLES; i++)
>      vt->vc_cons[i]->vc_kam =3D 1;

Finxed. I shoudl have been using find_vc and testing to see if I have a
vc present. I just commited the fix. Thank you.
=20
> linux-dj vgacon.c will be tested under ruby tomorrow.

It will not work since the functions calls in struct consw have changed.

> IMHO in all cycles You must add condition if(vt->vc_cons[i]) { ... }
> or move routines in vc_allocate() ;-)

I add the condition checks.=20

Re: Querying available input devices

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

On Sun, Mar 24, 2002 at 12:09:14PM +0100, Johann Deneux wrote:
> Vojtech Pavlik wrote:
> > On Fri, Mar 22, 2002 at 10:41:47AM +0100, Johann Deneux wrote:
> >>
> >>Another issue is the unplug-replug one:
> >>1 Game starts and opens /dev/input/js0 which handles a USB stick
> >>2 USB stick gets unplugged
> >>3 Game receives -ENODEV while trying to read, closes /dev/input/js0
> >>
> > 
> > Actually -ENODEV only works on /dev/input/event0. Joystick emulation
> > devices won't send -ENODEV, because most (old) applications won't know
> > how to handle that.
> > 
> 
> Oops, I changed that recently: joydev now returns -ENODEV. Should I 
> reverse the changes ?

I'm not sure - I think it shouldn't return -ENODEV, but, well, since if
you re-plug the joystick, it won't start working again anyway, we can
keep it as it is.

-- 
Vojtech Pavlik
SuSE Labs

Re: Querying available input devices

[Johann D. <de...@if...>]

Vojtech Pavlik wrote:
> On Fri, Mar 22, 2002 at 10:41:47AM +0100, Johann Deneux wrote:
>>
>>Another issue is the unplug-replug one:
>>1 Game starts and opens /dev/input/js0 which handles a USB stick
>>2 USB stick gets unplugged
>>3 Game receives -ENODEV while trying to read, closes /dev/input/js0
>>
> 
> Actually -ENODEV only works on /dev/input/event0. Joystick emulation
> devices won't send -ENODEV, because most (old) applications won't know
> how to handle that.
> 

Oops, I changed that recently: joydev now returns -ENODEV. Should I 
reverse the changes ?

-- 
Johann Deneux

Re: Participate?

[Wartan H. <wa...@so...>]

On Fri, Mar 22, 2002 at 12:16:34PM -0800, James Simmons wrote:

> Great!! I need the help since I'm lagging behind.

Ok :)

> unicode and support as many fonts as needed. Have any ideas about what the 
> screen buffer layout should be?

Hm. Perhaps, a two-dimensional massive with Unicoded symbols? Then
we'll have "native" Unicode support, and can do further translations,
map the massive to VGA/other videomemory, load fonts in the adapter
(the "module" implementing the real adapter, say VGA, could provide
functions to load font into the generator,  map our screenbuffer massive to
its videomemory)..


P.S. Sorry if these propasals are stupid, I'm only a starter ;)

-- 
Regards, Wartan.
echo "Your stdio isn't very std." 
		-- Larry Wall in Configure from the perl distribution

Re: Querying available input devices

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

On Fri, Mar 22, 2002 at 10:41:47AM +0100, Johann Deneux wrote:
> Hi,
> 
> It is often the case that games need to know the list of joysticks 
> available on the system.
> Currently, I see two ways of getting this information from userland:
> - Try to open each /dev/input/{event,js,mouse,whatever}* and use ioctls 
> to check who's there
> - Enable hotplug and make /sbin/hotplug to store this information somewhere

There is a third solution:

- Read /proc/bus/input/devices

> The first solution does not look too appealing to me (and that's an 
> understatement)
> The second seems a bit complicated to use, especially as it involves a 
> demon that might need to be modified.
> 
> Another issue is the unplug-replug one:
> 1 Game starts and opens /dev/input/js0 which handles a USB stick
> 2 USB stick gets unplugged
> 3 Game receives -ENODEV while trying to read, closes /dev/input/js0

Actually -ENODEV only works on /dev/input/event0. Joystick emulation
devices won't send -ENODEV, because most (old) applications won't know
how to handle that.

> 4 USB stick gets replugged into the same slot
> 5 Game detects it and re-opens it
> ...
> 
> How could 4 be realised ? The only solution I see is for the game to be 
> somehow signaled by a hotplug demon (could be done without using 
> signals, by polling a file, for example).

select() on /proc/bus/input/devices, or indeed a signal from the hotplug
daemon.

> Wouldn't it be simpler to use a /proc-based interface, instead of 
> emulating it with a demon. Is hotplug designed to handle these situations ?

Well, it might be simpler, an it's there because of that.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Johann D. <de...@if...>]

Quick fix (not yet tested): comment the kfree(iforce) in
iforce_delete_device in iforce-main.c. It's done twice (also in
iforce_serio_connect in iforce-serio.c), which is not a good thing to do.
Grmbl. I added this kfree to fix what I thought was a memory leak.
I don't know if it will solve your problem, but that's one fewer bug at
least.

'will make a patch after further testing. That is, not tonight, because 
of &@#$ exam on a saturday morning :(

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Johann D. <joh...@la...>]

Alexander Rawass wrote:
> Hi,
> 
> 
> On Monday 18 March 2002 13:37, you wrote:
> 
>>Alexander Rawass wrote:
>>
>>>Hi,
>>>
>>>I am having problems with my system, running kernel-2.4.17 with Johanns
>>>iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
>>>
>>>Sometimes, I am getting such errors:
>>>
>>>Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
>>>Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>>>Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>>>
>>>This bug also seems to happen only, when the joystick isn't switched on
>>>on startup/driver installation?
>>>
>>I am puzzled  ?-/
>>
> 
> This definetely happens only when the joystick is switched off at boot/driver 
> install time.
> 
> When It's on - everything's fine.
> 

What's the scenario ?
insmod input
insmod serio
insmod serport
insmod iforce
inputattach
<switch on joystick>

You *must* allways switch the stick on *before* starting inputattach. I 
will try to have a look at what happens when timeouts occur, though. 
That should never corrupt memory.

> When it's off - kmail goes kaboom when closing a window.
> 
> See attachments for dmesg output.
> 

If you could also run ksymoops on these messages, it would be very helpful.

-- 
Johann Deneux