linuxconsole-dev

multihead patches

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

miguel,

i wrote you a while ago about your work on multihead. i noticed your 
updates after you got a g450 (cool).

i would like to get a set of patches such that you can use the same 
xfree binary for either head. ideally, this same binary could be used by 
people not doing multihead so xfree could maybe merge the patch. do you 
think it could be based on your patch or should it be started from scratch?

i have a couple of questions from looking at the second-head patch 
http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/XFree86-4.1.0-2nd-0.92.patch

is there a way to avoid the pc-at keyboard hack code? why is it necessary?

do you still use the -delay switch?

brad

X compiled for evdev?

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

I see a note in linux/Documentation/input/input.txt about using X with 
the current input stuff for getting multihead. Has anyone built X with 
evdev support or is it standard via XFConfig manipulation?

either way I'd like to document this.

what about order detection? if two usb keyboards are attached, aren't 
they essentially randomly ordered? a long time ago i wrote an app for 
sorting this out via "press the 1 key" and "press the 2 key" etc on each 
head. do we have to do something like that?

=================================
3.2.4 evdev.o
~~~~~~~~~~~~~
    evdev is the generic input event interface. It passes the events
generated in the kernel straight to the program, with timestamps. The
API is still evolving, but should be useable now. It's described in
section 5.

    This should be the way for GPM and X to get keyboard and mouse mouse
events. It allows for multihead in X without any specific multihead
kernel support. The event codes are the same on all architectures and
are hardware independent.
==================================

brad

input pages

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

hi

were the input pages copied locally and put into cvs so they could be 
modified as part of this project? if so, that makes sense but i think 
i'd distill the relevant stuff into one or two pages so it's cleaner and 
easier to read/modify.

if they're going to be maintained in their current suse location, we 
should only link there (maybe deep-link to the quickstart in particular)

i am happy to help either way.

brad

Re: nVidia TNT2 32Mb PCI

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

>I would like to know if it's possible with your patch to setup a machine
>with two screens, 2 keybs, and 2 mouses (2 or more). My second video card
is a
>multihead video card, but the problem is to attatch a VT to it, and a
>xserver to the VT.
>
>Do you think it's possible with the actual state of the CVS?

You should have two separate video cards!

Any video device is binded with 16 /dev/tty's.
If You will run secondary X, I recomend add VGA and dummy console.
VGA binded with /dev/tty1-16
Dummy binded with /dev/tty17-32.

First X server start with "startx -- :0 vt7"
Second                    "startx -- :1 -xf86config XF-2-nd vt17"
Third shold have another dummy device.

I busy to test current "ruby".
If You have feeling "start ruby is impossible mission", You can
try another older version.


My version work on my two comps aprox 1 month.
User comp - 2 TNT2 M64 (PCI), 2 PS/2 keyboards, 2 serial mice.
With Athlon 1600 and 256Mb RAM kids can run all bunch of IDsoftware -
quake2,quake3,return to castle wolfenstein. These works simultaneous
through loopback driver can emulate net gaming.
All office apps work fine simultaneous.

Trouble is various. GLX samtimes hung up system.
Keyboard samtimes lack - X restart help.
USB keyboard incompatible with ALSA.

My patch against 2.4.18
My version has 8 tty's per video device.
You shouldn't use any framebuffer device.
http://startx.times.lv/bstreet.tar.bz2

Aivils Stoss

nVidia TNT2 32Mb PCI

[Henrion B. <bh...@ud...>]

Hello,

I would like to know if it's possible with your patch to setup a machine
with two screens, 2 keybs, and 2 mouses (2 or more). My second video card is a
multihead video card, but the problem is to attatch a VT to it, and a
xserver to the VT.

Do you think it's possible with the actual state of the CVS?

Thanks for your help

BNJ

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

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

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>>>> The point is that input.h should include the header defining uint16_t.
>>>>
>>> I don't think so. The kernel routines using uint16_t should include 
>>> the kernel header <linux/types.h>, while the userspace routines 
>>> should use the standard header (<stdint.h>).
>>>
>>
>> Perhaps a conditional include would do it ? I personally hate it when 
>> headers depending on other headers don't handle these dependencies by 
>> themselves, forcing the user to guess what could be the right thing to 
>> include in order to use some header. 
> 
> 
>        Me too...I'm not exactly sure what uint16_t would conflict with 
> if it were defined outside the kernel, but the fact is that it is only 
> defined within kernel code(see asm/types.h)...About being 

No. I think you completely missed the point. uint16_t *is* a standard 
C99 type defined in <stdint.h>. Did you have a look at the chapter 
indicated by Brad about the use of types in Linux drivers ?
See there: http://www.xml.com/ldd/chapter/book/ch10.html

> kernel-specific, the linux/input.h is kernel-dependant too, so I guess 
> maybe it's ok to use __u16??

Sure, it will still work.

>        How about making it more practical - will everything work if we 
> leave __u16?? 'cause non-kernel programs(such as fftest.c) have trouble 
> compiling with uint16_t...I don't see a reason not to leave it __u16 if 
> it works fine...

The argument would be "Why use the kernel-specific standard if there 
already is a C99 standard for this type ?".

The danger would be that a userland developer notices these __u16 types 
and starts using them in other places in his program. Later, he needs an 
unsigned 16-bits int. What type will he use ? He could be mislead into 
using __u16. The problem will arise when he wants to port his software 
to some other OS. __u16 won't be there. uint16_t will.

We could warn people and tell them not to use __u16. A better solution 
is not to show it at all.

Btw, I wonder what were hackers thinking when they decided to use u16 
for kernel-specific values and __u16 for public interfaces. Saying it's 
counter-intuitive is quite an understatement.


-- 
Johann Deneux

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>>> The point is that input.h should include the header defining uint16_t.
>>>
>> I don't think so. The kernel routines using uint16_t should include 
>> the kernel header <linux/types.h>, while the userspace routines 
>> should use the standard header (<stdint.h>).
>>
>
> Perhaps a conditional include would do it ? I personally hate it when 
> headers depending on other headers don't handle these dependencies by 
> themselves, forcing the user to guess what could be the right thing to 
> include in order to use some header. 

        Me too...I'm not exactly sure what uint16_t would conflict with 
if it were defined outside the kernel, but the fact is that it is only 
defined within kernel code(see asm/types.h)...About being 
kernel-specific, the linux/input.h is kernel-dependant too, so I guess 
maybe it's ok to use __u16??
        How about making it more practical - will everything work if we 
leave __u16?? 'cause non-kernel programs(such as fftest.c) have trouble 
compiling with uint16_t...I don't see a reason not to leave it __u16 if 
it works fine...

Rodrigo

-- 
* Rodrigo Damazio
* cu...@uo.../rod...@po.../rda...@ls...
* ICQ: #3560450         Homepage: http://www.vros.com/cuddly/
* Engenharia da Computação / Laboratório de Sistemas Integráveis(LSI)
* Escola Politécnica - USP - São Paulo

Re: [patch] joystick changes for 2.4.19-pre8 [was Re: evdev types]

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

On Sun, May 05, 2002 at 09:51:30PM +1000, Brad Hards wrote:

> On Sun, 5 May 2002 18:14, Brad Hards wrote:
> > I'll do the ->phys change though.
> Changes attached, against 2.4.19-pre8 + three previous changes.
> 
> I have tested this for compilation (not booted or tested though). Not sure 
> whether you want to put this in an -rc release or not.
> 
> Brad

It looks good, I'll read it thoroughly once more and then send all three to
Marcelo. OK?

-- 
Vojtech Pavlik
SuSE Labs

[patch] joystick changes for 2.4.19-pre8 [was Re: evdev types]

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

On Sun, 5 May 2002 18:14, Brad Hards wrote:
> I'll do the ->phys change though.
Changes attached, against 2.4.19-pre8 + three previous changes.

I have tested this for compilation (not booted or tested though). Not sure 
whether you want to put this in an -rc release or not.

Brad

Re: evdev types

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

On Fri, 3 May 2002 22:19, Vojtech Pavlik wrote:
> On Fri, May 03, 2002 at 10:02:05PM +1000, Brad Hards wrote:
> > On Fri, 3 May 2002 21:49, Vojtech Pavlik wrote:
> > > I did. However note that you'll most likely need to update the
> > > drivers/char/joystick drivers as well to follow the changes - not only
> > > USB uses input on 2.4 ...
> >
> > The USB stuff is what I can test. However I'd forgotten about the
> > joystick stuff. I might be able to find the adapter for a joystick which
> > turns it back into gameport, but won't be able to do them all.
> >
> > I'll have a look at this (and maybe the ADB stuff, which I had thought
> > about, and also can't test).
>
> It might be enough to copy them over from 2.5. Or at least make them
> compile (which shouldn't be too tough).
I have looked at the differences, and think that I don't need to add anything 
to 2.4, because all of the changes are extensions (although EVIOCGPHYS will 
fail, because not all drivers support it - although not all drivers support 
it in CVS or 2.5 either).

I'll do the ->phys change though.

Brad

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

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

Brad Hards wrote:
> On Sat, 4 May 2002 08:21, Johann Deneux wrote:
> 
>>Rodrigo Damazio wrote:
>>
>>>Update of /cvsroot/linuxconsole/ruby/linux/include/linux
>>>In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
>>>
>>>Modified Files:
>>>	input.h
>>>Log Message:
>>>Fix for the types problem - uint16_t and similars are not exported
>>>outside the kernel. They were replaced by __u16 and similars. fftest and
>>>other utils should now compile OK.
>>>
>>No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the
>>other way.
>>
>>I switched from __u16 to uint16_t on the advice of Brad Hards. The point
>>is that uint16_t is apparently a standard type (C99). __u16 is a
>>linux-kernel specific thing (16 bit unsigned integer visible from user
>>space).
>>The discussion went on on linux-usb, and apparently no agreement was
>>reached.
>>
> My reference was the Linux Device Drivers book (from O'Reilly, also available 
> on-line). Read the chapter on types for more info.

That's actually this chapter that convinced me to change to uint16_t.

> 
> 
>>The point is that input.h should include the header defining uint16_t.
>>
> I don't think so. The kernel routines using uint16_t should include the kernel 
> header <linux/types.h>, while the userspace routines should use the standard 
> header (<stdint.h>).
> 

Perhaps a conditional include would do it ? I personally hate it when 
headers depending on other headers don't handle these dependencies by 
themselves, forcing the user to guess what could be the right thing to 
include in order to use some header.

> 
>>I don't really care what we actually use. After all, an unsigned 16 bit
>>int remains an unsigned 16 bit int whatever we call it. But we should
>>settle this at once and make up our minds.
>>
> I only care for not confusing user-space programmers. Why use a non-standard 
> type, when a standard one is available?
> 
> Brad
> 
> 


-- 
Johann Deneux

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

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

On Sat, 4 May 2002 08:21, Johann Deneux wrote:
> Rodrigo Damazio wrote:
> > Update of /cvsroot/linuxconsole/ruby/linux/include/linux
> > In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
> >
> > Modified Files:
> > 	input.h
> > Log Message:
> > Fix for the types problem - uint16_t and similars are not exported
> > outside the kernel. They were replaced by __u16 and similars. fftest and
> > other utils should now compile OK.
>
> No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the
> other way.
>
> I switched from __u16 to uint16_t on the advice of Brad Hards. The point
> is that uint16_t is apparently a standard type (C99). __u16 is a
> linux-kernel specific thing (16 bit unsigned integer visible from user
> space).
> The discussion went on on linux-usb, and apparently no agreement was
> reached.
My reference was the Linux Device Drivers book (from O'Reilly, also available 
on-line). Read the chapter on types for more info.

> The point is that input.h should include the header defining uint16_t.
I don't think so. The kernel routines using uint16_t should include the kernel 
header <linux/types.h>, while the userspace routines should use the standard 
header (<stdint.h>).

> I don't really care what we actually use. After all, an unsigned 16 bit
> int remains an unsigned 16 bit int whatever we call it. But we should
> settle this at once and make up our minds.
I only care for not confusing user-space programmers. Why use a non-standard 
type, when a standard one is available?

Brad

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

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

Rodrigo Damazio wrote:
> Update of /cvsroot/linuxconsole/ruby/linux/include/linux
> In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
> 
> Modified Files:
> 	input.h 
> Log Message:
> Fix for the types problem - uint16_t and similars are not exported outside the kernel.
> They were replaced by __u16 and similars. fftest and other utils should now compile OK.
> 

No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the 
other way.

I switched from __u16 to uint16_t on the advice of Brad Hards. The point 
is that uint16_t is apparently a standard type (C99). __u16 is a 
linux-kernel specific thing (16 bit unsigned integer visible from user 
space).
The discussion went on on linux-usb, and apparently no agreement was 
reached.
The point is that input.h should include the header defining uint16_t. 
That would be a more proper fix.
I don't really care what we actually use. After all, an unsigned 16 bit 
int remains an unsigned 16 bit int whatever we call it. But we should 
settle this at once and make up our minds.

> 
> Index: input.h
> ===================================================================
> RCS file: /cvsroot/linuxconsole/ruby/linux/include/linux/input.h,v
> retrieving revision 1.65
> retrieving revision 1.66
> diff -u -d -r1.65 -r1.66
> --- input.h	15 Apr 2002 19:14:22 -0000	1.65
> +++ input.h	3 May 2002 18:47:12 -0000	1.66
> @@ -522,62 +522,62 @@
>   */
>  
>  struct ff_replay {
> -	uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
> -	uint16_t delay;  /* Time to wait before to start playing an effect */
> +	__u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
> +	__u16 delay;  /* Time to wait before to start playing an effect */
>  };
>  
> [And so on. Other undos of my earlier change]

-- 
Johann Deneux

Re: evdev types

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

On Fri, May 03, 2002 at 10:02:05PM +1000, Brad Hards wrote:

> On Fri, 3 May 2002 21:49, Vojtech Pavlik wrote:
> > I did. However note that you'll most likely need to update the
> > drivers/char/joystick drivers as well to follow the changes - not only
> > USB uses input on 2.4 ...
> The USB stuff is what I can test. However I'd forgotten about the joystick 
> stuff. I might be able to find the adapter for a joystick which turns it back 
> into gameport, but won't be able to do them all.
> 
> I'll have a look at this (and maybe the ADB stuff, which I had thought about, 
> and also can't test).

It might be enough to copy them over from 2.5. Or at least make them
compile (which shouldn't be too tough).

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Fri, 3 May 2002 21:49, Vojtech Pavlik wrote:
> I did. However note that you'll most likely need to update the
> drivers/char/joystick drivers as well to follow the changes - not only
> USB uses input on 2.4 ...
The USB stuff is what I can test. However I'd forgotten about the joystick 
stuff. I might be able to find the adapter for a joystick which turns it back 
into gameport, but won't be able to do them all.

I'll have a look at this (and maybe the ADB stuff, which I had thought about, 
and also can't test).

Brad

Re: evdev types

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

On Fri, May 03, 2002 at 09:38:15PM +1000, Brad Hards wrote:
> On Tue, 30 Apr 2002 00:42, Vojtech Pavlik wrote:
> > On Mon, Apr 29, 2002 at 09:24:55PM +1000, Brad Hards wrote:
> > > Patch 1 - changes to 2.4.19-pre7 from CVS that are userspace visible (ie
> > > the evdev ioctl's). I am doing it without my changes (and some equivalent
> > > changes to the new "set global state" ioctls). I will send those when
> > > this set is accepted.
> OK, I have completed this part, and done some simple testing. I haven't tested 
> every ioctl() - eg. I don't have a HID device with a serial number to test 
> the EVIOCGUNIQ ioctl.
> 
> The split is partly to reduce the size of each patch, and also so the 
> ioctldrivers patch (which is basically USB changes) can go to Greg K-H, if 
> required.
> 
> This change doesn't have the sprintf->snprintf change. I think it is safe the 
> way it is, and I'll clean it up in a future change. 2.4.19-pre is pretty late 
> (next change, rc1) and I'd prefer to only put in stuff that is basically the 
> same as 2.5/ linuxconsole CVS (or where I really understand what I am doing 
> :).
> 
> If this looks reasonable, can you pass this to Marcelo?

I did. However note that you'll most likely need to update the
drivers/char/joystick drivers as well to follow the changes - not only
USB uses input on 2.4 ...

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Tue, 30 Apr 2002 00:42, Vojtech Pavlik wrote:
> On Mon, Apr 29, 2002 at 09:24:55PM +1000, Brad Hards wrote:
> > Patch 1 - changes to 2.4.19-pre7 from CVS that are userspace visible (ie
> > the evdev ioctl's). I am doing it without my changes (and some equivalent
> > changes to the new "set global state" ioctls). I will send those when
> > this set is accepted.
OK, I have completed this part, and done some simple testing. I haven't tested 
every ioctl() - eg. I don't have a HID device with a serial number to test 
the EVIOCGUNIQ ioctl.

The split is partly to reduce the size of each patch, and also so the 
ioctldrivers patch (which is basically USB changes) can go to Greg K-H, if 
required.

This change doesn't have the sprintf->snprintf change. I think it is safe the 
way it is, and I'll clean it up in a future change. 2.4.19-pre is pretty late 
(next change, rc1) and I'd prefer to only put in stuff that is basically the 
same as 2.5/ linuxconsole CVS (or where I really understand what I am doing 
:).

If this looks reasonable, can you pass this to Marcelo?

Brad

Re: is ruby in the -dj tree

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

> >*o in -dj      Rewrite of the console layer
> <http://marc.theaimsgroup.com/?l=linux-kernel&m=98584133409891&w=2>
> (James Simmons)*
> 
> IMHO all pluged in keyboards works with one console.

Correct. The multiple keyboard has not been inplemented yet. I need every
keyboard ported over to the input api first.

Re: is ruby in the -dj tree

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

> Hi
> i suppose that this a misstake ,

Nope :-)

> *o in 2.5.11+  Rewrite of the framebuffer layer <http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html>                (James Simmons)*

Yes the new framework went in. The old hooks still exist so not to break
every fbdev driver. Now the old drivers can be ported over to the new api.
 
> *o in -dj      Rewrite of the console layer <http://marc.theaimsgroup.com/?l=linux-kernel&m=98584133409891&w=2>                    (James Simmons)*

Yes par tof it went in. Alot more has to go in tho. 

> and AFAIK there was nothing from the console layer as of 2.5.9-dj1

Yes there is. Take a look at drivers/char!!! Not all of the ruby tree has
been moved over tho. I want to port as many drivers over to the input api
and new fbdev api as possible. Then push the console stuff. Plus I have
more plans for the console code that I haven't got around to yet. Then
their is the serial layer rewrite which I haven't worked on yet either.

> only the fb and input layers were included
> 
> am i missing smth.

Re: is ruby in the -dj tree

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

>*o in -dj      Rewrite of the console layer
<http://marc.theaimsgroup.com/?l=linux-kernel&m=98584133409891&w=2>
(James Simmons)*

IMHO all pluged in keyboards works with one console.

You shall not be able start multiple framebuffer or X with separate
keyboards.
We wait when "vt_map_input" to be pushed into linux-dj :-)

Aivils Stoss

Re: evdev types

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

On Mon, Apr 29, 2002 at 09:24:55PM +1000, Brad Hards wrote:
> On Tue, 23 Apr 2002 01:10, Vojtech Pavlik wrote:
> > On Mon, Apr 22, 2002 at 06:40:25PM +1000, Brad Hards wrote:
> <snip>
> > > I can maybe do some patches for the input system for 2.4 if you just need
> > > grunt work.
> >
> > It would be nice, if you could. I'm rather low on time right now (should
> > be better after a couple weeks), because of other projects (robotic cup,
> > wedding, ...).
> Congratulations!
> 
> I am working on the patches.
> 
> I am trying for the following breakdown:
> Patch 1 - changes to 2.4.19-pre7 from CVS that are userspace visible (ie the 
> evdev ioctl's). I am doing it without my changes (and some equivalent changes 
> to the new "set global state" ioctls). I will send those when this set is 
> accepted.
> 
> Patch 2 - changes to 2.4.19-pre7 from CVS to implement the revised modular 
> system, including hotplug
> 
> Patch 3 - changes to 2.4.19-pre7 from CVS to implement /proc
> 
> Patch 4 - changes to 2.4.19-pre8 (or whatever patch the first three go into, 
> plus 1 non-rc)  from CVS for FF.
> 
> Patch 5 - minor changes (Vojtech's email address, Suse deletion, etc)
> 
> Patch 6 (in 2.4.20-pre, probably) to provide structures for ioctl argp's, as 
> appropriate, based on my prior set of patches.

Ok.

> Questions:
> 1. Johann - do you think the FF stuff is stable enough? I don't have any 
> device to try it yet, so I think that maybe I have to defer Patch 4 to you.
> 
> 2. I'm not planning to make patches for evbug, power or tsdev drivers into 2.4 
> at this stage. Does this seem reasonable to developers? Also, I'm leaving out 
> all the pm stuff - again, does this seem reasonable at this stage?

Yes.

> 3. In input.c:input_call_hotplug(), there is a KERN_ERR that says:
> "input.c: calling hotplug a hotplug agent defined\n"
> is that supposed to be:
> "input.c: calling hotplug without a hotplug agent defined\n" ?

That's right.

> 4, The patches will likely be fairly large  (circa 2000 lines). Do developers 
> want to see them posted to the list as well as sent to Vojtech for 
> onforwarding to Marcelo?
> 
> Brad

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

Brad Hards wrote:
> On Tue, 23 Apr 2002 01:10, Vojtech Pavlik wrote:
> 
>>On Mon, Apr 22, 2002 at 06:40:25PM +1000, Brad Hards wrote:
>>
> <snip>
> 
>>>I can maybe do some patches for the input system for 2.4 if you just need
>>>grunt work.
>>>
>>It would be nice, if you could. I'm rather low on time right now (should
>>be better after a couple weeks), because of other projects (robotic cup,
>>wedding, ...).
>>
> Congratulations!
> 
> I am working on the patches.
> 
> I am trying for the following breakdown:
> Patch 1 - changes to 2.4.19-pre7 from CVS that are userspace visible (ie the 
> evdev ioctl's). I am doing it without my changes (and some equivalent changes 
> to the new "set global state" ioctls). I will send those when this set is 
> accepted.
> 
> Patch 2 - changes to 2.4.19-pre7 from CVS to implement the revised modular 
> system, including hotplug
> 
> Patch 3 - changes to 2.4.19-pre7 from CVS to implement /proc
> 
> Patch 4 - changes to 2.4.19-pre8 (or whatever patch the first three go into, 
> plus 1 non-rc)  from CVS for FF.
> 
> Patch 5 - minor changes (Vojtech's email address, Suse deletion, etc)
> 
> Patch 6 (in 2.4.20-pre, probably) to provide structures for ioctl argp's, as 
> appropriate, based on my prior set of patches.
> 
> Questions:
> 1. Johann - do you think the FF stuff is stable enough? I don't have any 
> device to try it yet, so I think that maybe I have to defer Patch 4 to you.
> 

You mean the API or the drivers ? The API looks ok, except for the 
rumble effects. There is a big chance that struct ff_rumble_effect 
changes. Other ff* stuff shouldn't move.
The I-Force driver is stable enough to be actually used in games. Other 
drivers (PID, Logitech) aren't yet functional.

I can take care of this patch.

> 2. I'm not planning to make patches for evbug, power or tsdev drivers into 2.4 
> at this stage. Does this seem reasonable to developers? Also, I'm leaving out 
> all the pm stuff - again, does this seem reasonable at this stage?
> 
> 3. In input.c:input_call_hotplug(), there is a KERN_ERR that says:
> "input.c: calling hotplug a hotplug agent defined\n"
> is that supposed to be:
> "input.c: calling hotplug without a hotplug agent defined\n" ?
> 
> 4, The patches will likely be fairly large  (circa 2000 lines). Do developers 
> want to see them posted to the list as well as sent to Vojtech for 
> onforwarding to Marcelo?

I don't mind receiving big mails, but I can't talk for everyone. Perhaps 
you could make them available by ftp or http and post the URL ?

-- 
Johann Deneux

Re: evdev types

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

On Tue, 23 Apr 2002 01:10, Vojtech Pavlik wrote:
> On Mon, Apr 22, 2002 at 06:40:25PM +1000, Brad Hards wrote:
<snip>
> > I can maybe do some patches for the input system for 2.4 if you just need
> > grunt work.
>
> It would be nice, if you could. I'm rather low on time right now (should
> be better after a couple weeks), because of other projects (robotic cup,
> wedding, ...).
Congratulations!

I am working on the patches.

I am trying for the following breakdown:
Patch 1 - changes to 2.4.19-pre7 from CVS that are userspace visible (ie the 
evdev ioctl's). I am doing it without my changes (and some equivalent changes 
to the new "set global state" ioctls). I will send those when this set is 
accepted.

Patch 2 - changes to 2.4.19-pre7 from CVS to implement the revised modular 
system, including hotplug

Patch 3 - changes to 2.4.19-pre7 from CVS to implement /proc

Patch 4 - changes to 2.4.19-pre8 (or whatever patch the first three go into, 
plus 1 non-rc)  from CVS for FF.

Patch 5 - minor changes (Vojtech's email address, Suse deletion, etc)

Patch 6 (in 2.4.20-pre, probably) to provide structures for ioctl argp's, as 
appropriate, based on my prior set of patches.

Questions:
1. Johann - do you think the FF stuff is stable enough? I don't have any 
device to try it yet, so I think that maybe I have to defer Patch 4 to you.

2. I'm not planning to make patches for evbug, power or tsdev drivers into 2.4 
at this stage. Does this seem reasonable to developers? Also, I'm leaving out 
all the pm stuff - again, does this seem reasonable at this stage?

3. In input.c:input_call_hotplug(), there is a KERN_ERR that says:
"input.c: calling hotplug a hotplug agent defined\n"
is that supposed to be:
"input.c: calling hotplug without a hotplug agent defined\n" ?

4, The patches will likely be fairly large  (circa 2000 lines). Do developers 
want to see them posted to the list as well as sent to Vojtech for 
onforwarding to Marcelo?

Brad

is ruby in the -dj tree

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

Hi
i suppose that this a misstake ,

so the latest kernel status says

*o in 2.5.11   Fast walk dcache <http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.0/1752.html>                                (Hanna Linder)*
*o in 2.5.11+  Rewrite of the framebuffer layer <http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html>                (James Simmons)*

*o in -dj      Rewrite of the console layer <http://marc.theaimsgroup.com/?l=linux-kernel&m=98584133409891&w=2>                    (James Simmons)*
o in -ac      Strict address space accounting <http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/0364.html>                 (Alan Cox)
o in -ac      PCMCIA Zoom video support <http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html>                       (Alan Cox)

and AFAIK there was nothing from the console layer as of 2.5.9-dj1
only the fb and input layers were included

am i missing smth.

svetljo

Same ask for web I ask for Code

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

Hi

When lead maintainer plan test their creature onto real hardware?
Now any user must have personal code repositary to avert DAMAGE OF JAMES :)


Aivils Stoss