[PATCH 0/5] Sonypi driver model & PM changes

[PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

Hi,

I have been looking at the sysdevs in present in the kernel and noticed that
sonypi was registering itself as a system device. Surely it is possible to
suspend it with interrupyts enabled, so it better be converted to a platform
device. I course of convert I also did some additional changes:

01-sonypi-whitespace-fixes.patch
	- get rid of extra whitespace and convert to the kernel cosing style:
	  ... However, there is one special case, namely functions: they have
	  the opening brace at the beginning of the next line...

02-sonypi-module_param.patch
	- convert sonypi from using MODULE_PARM and __setup to module_param.
	  The parameters are:
		sonypi.camera
		sonypi.compat
		sonypi.fnkeyinit
		sonypi.mask=		- exported through sysfs, writeable
		sonypi.minor=
		sonypi.useinput
		sonypi.verbose		- exported through sysfs, writeable

03-sonypi-pm-changes.patch
	- convert sonypi sysdev to platform device, drop old-style PM code
	  since APM does call device_suspend anyway so the new style handlers
          will be called.

04-sonypi-misc-changes.patch
	- switch sonypi_misc_read to use wake_event_interruptible instead of
	  a homemade copy, fix small race there, make sure that the device
	  is fully initialized before turning the interrupts on.	

05-sonypi-pci_get_device.patch
	- convert from pci_find_device which is obsolete to pci_get_device.

Warning: I do not have the hardware som while the code is compiles and I am
pretty sure it is correct it has not been tested.

Should apply to 2.6.9

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Thu, Oct 21, 2004 at 01:54:58AM -0500, Dmitry Torokhov wrote:

> I have been looking at the sysdevs in present in the kernel and noticed that
> sonypi was registering itself as a system device. Surely it is possible to
> suspend it with interrupyts enabled, so it better be converted to a platform
> device. I course of convert I also did some additional changes:
[...]

Thanks for those patches and sorry for the lack of response, I was out
of town for the last week.

I have quite a few changes in my tree already for the sonypi driver,
and I was delaying the submission because I need to solve a problem
with the integration with the input subsystem...

Some of your changes (those related to module_param(), wait_event()
use etc) were already in my tree, those related to whitespace cleanup,
platform instead of sysdev etc are new and I will integrate them.

Let me work a bit on those, and I will try to separate my changes
and resubmit them in the next days.

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

On Monday 25 October 2004 07:56 am, Stelian Pop wrote:
> On Thu, Oct 21, 2004 at 01:54:58AM -0500, Dmitry Torokhov wrote:
> 
> > I have been looking at the sysdevs in present in the kernel and noticed that
> > sonypi was registering itself as a system device. Surely it is possible to
> > suspend it with interrupyts enabled, so it better be converted to a platform
> > device. I course of convert I also did some additional changes:
> [...]
> 
> Thanks for those patches and sorry for the lack of response, I was out
> of town for the last week.
> 
> I have quite a few changes in my tree already for the sonypi driver,
> and I was delaying the submission because I need to solve a problem
> with the integration with the input subsystem...
>

If you need a hand - I am a bit familiar with the input system...
 
> Some of your changes (those related to module_param(), wait_event()
> use etc) were already in my tree, those related to whitespace cleanup,
> platform instead of sysdev etc are new and I will integrate them.
>

The change from sysdev to a platform device is the main reason I did
the change (and getting rid of old pm_register stuff which is useless
now) because swsusp2 (and seems that swsusp1 as well) have trouble
resuming system devices. The rest was just fluff really.

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 02:56:29PM +0200, Stelian Pop wrote:

> I have quite a few changes in my tree already for the sonypi driver,
> and I was delaying the submission because I need to solve a problem
> with the integration with the input subsystem...

Speaking of this, Vojtech, how should I proceed ?

Let me remind you the problem: I am in the process of converting
the sonypi driver to (fully) use the input subsystem to forward 
special key presses to X and the console instead of using a userspace
daemon which pushes the KeyPress events into the X queue.

The special keys are like KEY_BACK, KEY_HELP, KEY_ZOOM, KEY_CAMERA,
and a dozen FN + some key combinations.

I can integrate those events into the input layer in 2 different ways:

* allocate a new key event (in include/linux/input.h) for each
  key *and* combination. This will make the keys and the combinations
  work both on the console and in X.

  Unfortunately only events under the 0xff limit seem to be
  propagated to X, the other ones don't generate any X event (I haven't
  looked at the problem but I suppose it somewhere into the X code).

  showkey does corectly see the keys in raw mode.

* allocate a FN key event and let FN be a modifier.

  This is much nicer (less events allocated in input.h), but I haven't
  found a way (and I'm not sure there is one) to say to X that Fn is a 
  *new* modifier. Yes, I can say FN act like a Control, Meta or whatever
  existing modifier, but this is useless since I already have a Control,
  Alt, etc. key on my keyboard. The whole point is to add support for 
  a new key !

  I also haven't looked yet at adding a new modifier in the console
  mode...

Please advice on the recommended way to do this properly.

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 08:22:46AM -0500, Dmitry Torokhov wrote:

> If you need a hand - I am a bit familiar with the input system...

See the other mail I just send CC:'ed to Vojtech...

> > Some of your changes (those related to module_param(), wait_event()
> > use etc) were already in my tree, those related to whitespace cleanup,
> > platform instead of sysdev etc are new and I will integrate them.
> >
> 
> The change from sysdev to a platform device is the main reason I did
> the change (and getting rid of old pm_register stuff which is useless
> now) because swsusp2 (and seems that swsusp1 as well) have trouble
> resuming system devices. The rest was just fluff really.

Ok. Suspending never really worked on my laptop so I'll have to assume
you're correct. :)

[ Just tried once again to do a suspend to ram, seems that there were
some enhancements in this area lately. 

  No luck. Machine suspends ok, but upon waking up, the power led goes
  greek ok, the disk led lights up, but the keyboard is dead, the
  network card is dead, the screen doesn't turn on...

  Since this laptop has no serial port I don't see what else I can do,
  except wait another 6 months and try again... :(
]

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Vojtech Pavlik]

On Mon, Oct 25, 2004 at 03:50:36PM +0200, Stelian Pop wrote:

> The special keys are like KEY_BACK, KEY_HELP, KEY_ZOOM, KEY_CAMERA,
> and a dozen FN + some key combinations.
> 
> I can integrate those events into the input layer in 2 different ways:
> 
> * allocate a new key event (in include/linux/input.h) for each
>   key *and* combination. This will make the keys and the combinations
>   work both on the console and in X.
> 
>   Unfortunately only events under the 0xff limit seem to be
>   propagated to X, the other ones don't generate any X event (I haven't
>   looked at the problem but I suppose it somewhere into the X code).

The number is 240 and it's the number of possible PS/2 scancode
combinations, and since at this time X can only understand the PS/2
protocol (and not native Linux events), this is the only way how to pass
keypresses to X.

I believe that although this way may be easier, it leads to madness.

>   showkey does corectly see the keys in raw mode.
> 
> * allocate a FN key event and let FN be a modifier.
> 
>   This is much nicer (less events allocated in input.h), but I haven't
>   found a way (and I'm not sure there is one) to say to X that Fn is a 
>   *new* modifier. Yes, I can say FN act like a Control, Meta or whatever
>   existing modifier, but this is useless since I already have a Control,
>   Alt, etc. key on my keyboard. The whole point is to add support for 
>   a new key !
> 
>   I also haven't looked yet at adding a new modifier in the console
>   mode...
 
IIRC X has only 8 modifier keys and all are already defined and you
can't define any more. But I doubt you're using all of them on your
keyboard. It should be possible to assign Fn to one of them.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 03:57:43PM +0200, Vojtech Pavlik wrote:

> The number is 240 and it's the number of possible PS/2 scancode
> combinations, and since at this time X can only understand the PS/2
> protocol (and not native Linux events), this is the only way how to pass
> keypresses to X.
> 
> I believe that although this way may be easier, it leads to madness.

It is also impossible for me to go this way because there is no way
to put 20+ events between 226 and 240...

> >   I also haven't looked yet at adding a new modifier in the console
> >   mode...
>  
> IIRC X has only 8 modifier keys and all are already defined and you
> can't define any more. But I doubt you're using all of them on your
> keyboard. It should be possible to assign Fn to one of them.

That's what I thought too. However, it seems to work only when the
keysym associated with the modifier is a well known key (Control_L,
Control_R, Alt_L etc).

If I do (214 is the keycode generated by my Fn key):
	keycode 214 = Control_L
	clear mod3
	add mod3 = Control_L
then Fn + F1 will generate Mod3 + F1 (but Control_L will not work as 
a Control modifier anymore).

But if I do:
	keycode 214 = function
	clear mod3
	add mod3 = function
then (at least) WindowMaker does not see the modifier anymore (only
a 'function' single key press is received).

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 05:11:22PM +0200, Vojtech Pavlik wrote:

> > > I believe that although this way may be easier, it leads to madness.
> > 
> > It is also impossible for me to go this way because there is no way
> > to put 20+ events between 226 and 240...
> 
> You could fix X to use either medium raw mode on the console or the
> event protocol. Medium raw has a limit of 2^14 and event protocol is
> limited by 2^16.

Well, letting X get the events directly on /dev/input/event* is clearly
the way to go, for a long term solution.

However, I would like a short term solution, available now, so users
of sonypi could just migrate towards the new way without having to
compile their own version of the X server...

> > That's what I thought too. However, it seems to work only when the
> > keysym associated with the modifier is a well known key (Control_L,
> > Control_R, Alt_L etc).
> > 
> > If I do (214 is the keycode generated by my Fn key):
> > 	keycode 214 = Control_L
> > 	clear mod3
> > 	add mod3 = Control_L
> > then Fn + F1 will generate Mod3 + F1 (but Control_L will not work as 
> > a Control modifier anymore).
> > 
> > But if I do:
> > 	keycode 214 = function
> > 	clear mod3
> > 	add mod3 = function
> > then (at least) WindowMaker does not see the modifier anymore (only
> > a 'function' single key press is received).
> 
> Does the same happen in 'xev'?

xev doesn't say anything about modifiers. It shows the modifier being
pressed, the other key pressed, then released, then the modifier being
released too.

The trace shows the same kind of events in a working Control case or
in a not working 'function' case:

KeyPress event, serial 24, synthetic NO, window 0x2a00001,
    root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
    state 0x0, keycode 214 (keysym 0x8f6, function), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 24, synthetic NO, window 0x2a00001,
    root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
    state 0x20, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 24, synthetic NO, window 0x2a00001,
    root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
    state 0x20, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes: 

KeyRelease event, serial 24, synthetic NO, window 0x2a00001,
    root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
    state 0x20, keycode 214 (keysym 0x8f6, function), same_screen YES,
    XLookupString gives 0 bytes: 

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

Apologies for breaking the threading...

Stelian Pop wrote:
> On Mon, Oct 25, 2004 at 03:57:43PM +0200, Vojtech Pavlik wrote:
> 
> > The number is 240 and it's the number of possible PS/2 scancode
> > combinations, and since at this time X can only understand the PS/2
> > protocol (and not native Linux events), this is the only way how to pass
> > keypresses to X.
> >
> > I believe that although this way may be easier, it leads to madness.
> 
> It is also impossible for me to go this way because there is no way
> to put 20+ events between 226 and 240...
> 

I'd say just allocate brand new events for all combinations and do not
worry that the default X keyboard drivers to not get them. There are
already patches in Gentoo adding both keyboard and mouse event support
to X [1] and it is only matter of time ofr other duistributions to pick
it up as well.

I think it is sensible for an supplemental driver (sonypi) to require
some additional support form userspace and not to force itself into
boundaries of a legacy protocol.

-- 
Dmitry

[1] 
http://csociety-ftp.ecn.purdue.edu/pub/gentoo/distfiles/xorg-x11-6.8.0-patches-0.2.5.tar.bz2
Extract patches 9000, 9001 and 9002. Btw, these are not mine - I have
Not even tries them myself but I have read several success stories.

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Vojtech Pavlik]

On Mon, Oct 25, 2004 at 05:20:24PM +0200, Stelian Pop wrote:
> xev doesn't say anything about modifiers. It shows the modifier being
> pressed, the other key pressed, then released, then the modifier being
> released too.
> 
> The trace shows the same kind of events in a working Control case or
> in a not working 'function' case:
> 
> KeyPress event, serial 24, synthetic NO, window 0x2a00001,
>     root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
>     state 0x0, keycode 214 (keysym 0x8f6, function), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> KeyPress event, serial 24, synthetic NO, window 0x2a00001,
>     root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
>     state 0x20, keycode 67 (keysym 0xffbe, F1), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 24, synthetic NO, window 0x2a00001,
>     root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
>     state 0x20, keycode 67 (keysym 0xffbe, F1), same_screen YES,
>     XLookupString gives 0 bytes: 
> 
> KeyRelease event, serial 24, synthetic NO, window 0x2a00001,
>     root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
>     state 0x20, keycode 214 (keysym 0x8f6, function), same_screen YES,
>     XLookupString gives 0 bytes: 
 
Watch the "state" variable.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Pavel Machek]

Hi!

> > If you need a hand - I am a bit familiar with the input system...
> 
> See the other mail I just send CC:'ed to Vojtech...
> 
> > > Some of your changes (those related to module_param(), wait_event()
> > > use etc) were already in my tree, those related to whitespace cleanup,
> > > platform instead of sysdev etc are new and I will integrate them.
> > >
> > 
> > The change from sysdev to a platform device is the main reason I did
> > the change (and getting rid of old pm_register stuff which is useless
> > now) because swsusp2 (and seems that swsusp1 as well) have trouble
> > resuming system devices. The rest was just fluff really.
> 
> Ok. Suspending never really worked on my laptop so I'll have to assume
> you're correct. :)
> 
> [ Just tried once again to do a suspend to ram, seems that there were
> some enhancements in this area lately. 
> 
>   No luck. Machine suspends ok, but upon waking up, the power led goes
>   greek ok, the disk led lights up, but the keyboard is dead, the
>   network card is dead, the screen doesn't turn on...
> 
>   Since this laptop has no serial port I don't see what else I can do,
>   except wait another 6 months and try again... :(

Debug using pc speaker... Or paralel port, or something like that.

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Pavel Machek]

Hi!

> * allocate a FN key event and let FN be a modifier.
> 
>   This is much nicer (less events allocated in input.h), but I haven't
>   found a way (and I'm not sure there is one) to say to X that Fn is

I think this is *bad* idea. In such case, userland would see
Fn-F3. My notebook has "sleep" key on Fn-F3, but your notebook
probably has something else there. You'd need another mapping in
userspace...

I believe Fn-F3 on my machine is meant to be replacement for hardware
sleep button (and it has sleep label on it!), and we really should
generate sleep event for Fn-F3...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Nigel Cunningham]

Hi.

On Mon, 2004-10-25 at 23:22, Dmitry Torokhov wrote:
> The change from sysdev to a platform device is the main reason I did
> the change (and getting rid of old pm_register stuff which is useless
> now) because swsusp2 (and seems that swsusp1 as well) have trouble
> resuming system devices. The rest was just fluff really.

I'm not sure why we're not trying to resume system devices. I'll give it
a whirl and see if anything breaks :> Feel free to tell me if/when you
notice things like this in future; I try to be approachable and
responsive.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Everyone lives by faith. Some people just don't believe it.
Want proof? Try to prove that the theory of evolution is true.

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Tue, Oct 26, 2004 at 12:09:21AM +0200, Pavel Machek wrote:

> > Ok. Suspending never really worked on my laptop so I'll have to assume
> > you're correct. :)
> > 
> > [ Just tried once again to do a suspend to ram, seems that there were
> > some enhancements in this area lately. 
> > 
> >   No luck. Machine suspends ok, but upon waking up, the power led goes
> >   greek ok, the disk led lights up, but the keyboard is dead, the
> >   network card is dead, the screen doesn't turn on...
> > 
> >   Since this laptop has no serial port I don't see what else I can do,
> >   except wait another 6 months and try again... :(
> 
> Debug using pc speaker... Or paralel port, or something like that.

This is a laptop which has no serial or parallel port.

All the interfaces it has are all too high level to be used for
debugging (USB, firewire, pcmcia etc).

I think the speaker would probably work. I'll give it a try and
see if it helps next time...

Stelian.
-- 
Stelian Pop <stelian@popies.net>

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

On Tuesday 26 October 2004 12:55 am, Stelian Pop wrote:
> On Tue, Oct 26, 2004 at 12:09:21AM +0200, Pavel Machek wrote:
> 
> > > Ok. Suspending never really worked on my laptop so I'll have to assume
> > > you're correct. :)
> > > 
> > > [ Just tried once again to do a suspend to ram, seems that there were
> > > some enhancements in this area lately. 
> > > 
> > >   No luck. Machine suspends ok, but upon waking up, the power led goes
> > >   greek ok, the disk led lights up, but the keyboard is dead, the
> > >   network card is dead, the screen doesn't turn on...
> > > 
> > >   Since this laptop has no serial port I don't see what else I can do,
> > >   except wait another 6 months and try again... :(
> > 
> > Debug using pc speaker... Or paralel port, or something like that.
> 
> This is a laptop which has no serial or parallel port.
> 
> All the interfaces it has are all too high level to be used for
> debugging (USB, firewire, pcmcia etc).
> 
> I think the speaker would probably work. I'll give it a try and
> see if it helps next time...
> 

I'd try to get suspend-to-disk working first.. ACPI S3 seems to be much
trickier.

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

On Monday 25 October 2004 09:28 pm, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2004-10-25 at 23:22, Dmitry Torokhov wrote:
> > The change from sysdev to a platform device is the main reason I did
> > the change (and getting rid of old pm_register stuff which is useless
> > now) because swsusp2 (and seems that swsusp1 as well) have trouble
> > resuming system devices. The rest was just fluff really.
> 
> I'm not sure why we're not trying to resume system devices. I'll give it
> a whirl and see if anything breaks :> Feel free to tell me if/when you
> notice things like this in future; I try to be approachable and
> responsive.
> 

Hi Nigel,
 
System devices are resumed when you call device_power_up and I could
not find references to it in swsusp2 code, it goes straight to
device_resume_tree... Am I missng something?

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Nigel Cunningham]

Hi.

On Tue, 2004-10-26 at 16:21, Dmitry Torokhov wrote:
> On Monday 25 October 2004 09:28 pm, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Mon, 2004-10-25 at 23:22, Dmitry Torokhov wrote:
> > > The change from sysdev to a platform device is the main reason I did
> > > the change (and getting rid of old pm_register stuff which is useless
> > > now) because swsusp2 (and seems that swsusp1 as well) have trouble
> > > resuming system devices. The rest was just fluff really.
> > 
> > I'm not sure why we're not trying to resume system devices. I'll give it
> > a whirl and see if anything breaks :> Feel free to tell me if/when you
> > notice things like this in future; I try to be approachable and
> > responsive.
> > 
> 
> Hi Nigel,
>  
> System devices are resumed when you call device_power_up and I could
> not find references to it in swsusp2 code, it goes straight to
> device_resume_tree... Am I missng something?

No, you weren't. I was following the pattern of Patrick and Pavel. I've
changed it this afternoon and have it running fine, except that the PIC
timer code takes a few seconds (see separate message).

The changes will be in 2.1.1. I just have a couple more little fixes to
do before I release it.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Everyone lives by faith. Some people just don't believe it.
Want proof? Try to prove that the theory of evolution is true.

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Karol Kozimor]

On Tuesday 26 of October 2004 00:12, Pavel Machek wrote:
> > * allocate a FN key event and let FN be a modifier.
> >
> >   This is much nicer (less events allocated in input.h), but I haven't
> >   found a way (and I'm not sure there is one) to say to X that Fn is
>
> I think this is *bad* idea. In such case, userland would see
> Fn-F3. My notebook has "sleep" key on Fn-F3, but your notebook
> probably has something else there. You'd need another mapping in
> userspace...
>
> I believe Fn-F3 on my machine is meant to be replacement for hardware
> sleep button (and it has sleep label on it!), and we really should
> generate sleep event for Fn-F3...

Then map the button to invoke the suspend script in userspace. First we're 
mapping ACPI events to input events, then the other way around? Sounds 
fishy to me.
Best regards,

-- 
Karol Kozimor
kkozimor@aurox.org

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 08:20:29AM -0700, Dmitry Torokhov wrote:

> I'd say just allocate brand new events for all combinations and do not
> worry that the default X keyboard drivers to not get them. There are
> already patches in Gentoo adding both keyboard and mouse event support
> to X [1] and it is only matter of time ofr other duistributions to pick
> it up as well.
> 
> I think it is sensible for an supplemental driver (sonypi) to require
> some additional support form userspace and not to force itself into
> boundaries of a legacy protocol.
> 
> -- 
> Dmitry
> 
> [1] 
> http://csociety-ftp.ecn.purdue.edu/pub/gentoo/distfiles/xorg-x11-6.8.0-patches-0.2.5.tar.bz2
> Extract patches 9000, 9001 and 9002. Btw, these are not mine - I have
> Not even tries them myself but I have read several success stories.

Got them and trying to build the new drivers right now. Thanks !

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Mon, Oct 25, 2004 at 06:04:27PM +0200, Vojtech Pavlik wrote:

> > KeyRelease event, serial 24, synthetic NO, window 0x2a00001,
> >     root 0x40, subw 0x2a00002, time 6566259, (37,47), root:(542,70),
> >     state 0x20, keycode 214 (keysym 0x8f6, function), same_screen YES,
> >     XLookupString gives 0 bytes: 
>  
> Watch the "state" variable.

Indeed, I didn't noticed it.

However, this still doesn't work as expected. I looked at WindowMaker's
code for grabbing a key and found out it uses the standard IsModifierKey
macro, which is defined in X11/Xutil.h as:

#define IsModifierKey(keysym) \
  ((((KeySym)(keysym) >= XK_Shift_L) && ((KeySym)(keysym) <= XK_Hyper_R)) \
  || (((KeySym)(keysym) >= XK_ISO_Lock) && \
       ((KeySym)(keysym) <= XK_ISO_Last_Group_Lock)) \
  || ((KeySym)(keysym) == XK_Mode_switch) \
  || ((KeySym)(keysym) == XK_Num_Lock))

So it clearly handles only some special modifier keys.

Moreover, the xkeycaps manpage (available at
http://wwwvms.mppmu.mpg.de/unix_man_pages/xkeycaps.html) goes a bit
more in-depth and says:

   Modifier Bit
                 Modifier  bits  are  attributes  which   certain
                 keysyms  can have.  Some modifier bits have pre­
                 defined semantics:  Shift,  Lock,  and  Control.
                 The  remaining modifier bits (Mod1 through Mod5)
                 have semantics which are  defined  by  the  keys
                 with which they are associated.

So I'm back where I started, I cannot see how to define my new
'Fn' key to be interpreted as a 'ModX' modifier by X.

I will probably go now the new evdev based X driver, and will use
new, above 240, keycodes for all key combinations. Provided the
Gentoo patches build and work correctly.

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Tue, Oct 26, 2004 at 11:28:02AM +0200, Stelian Pop wrote:

> > [1] 
> > http://csociety-ftp.ecn.purdue.edu/pub/gentoo/distfiles/xorg-x11-6.8.0-patches-0.2.5.tar.bz2
> > Extract patches 9000, 9001 and 9002. Btw, these are not mine - I have
> > Not even tries them myself but I have read several success stories.
> 
> Got them and trying to build the new drivers right now. Thanks !

Well, it kinda works, but there are still some rough edges (the kbd
driver maps all the unknown keys to KEY_UNKNOWN, making them all to
have the same keycode in X, making them unusable. After removing the
test it forwards the events ok).

There are also problems because my sonypi input device acts both like
a mouse and a keyboard, and the X event driver wants them to be separate.

Vojtech: should I generate two different input devices in my driver,
a mouse like and a keyboard like device, or should the userspace be
able to demultiplex the events ?

Stelian.
-- 
Stelian Pop <stelian@popies.net>    

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

And I am breaking the thread yet again....

Stelian pop wrote:
> On Tue, Oct 26, 2004 at 11:28:02AM +0200, Stelian Pop wrote:
> 
> > > [1]
> > > http://csociety-ftp.ecn.purdue.edu/pub/gentoo/distfiles/xorg-x11-
> 6.8.0-patches-0.2.5.tar.bz2
> > > Extract patches 9000, 9001 and 9002. Btw, these are not mine - I have
> > > Not even tries them myself but I have read several success stories.
> >
> > Got them and trying to build the new drivers right now. Thanks !
> 
> Well, it kinda works, but there are still some rough edges (the kbd
> driver maps all the unknown keys to KEY_UNKNOWN, making them all to
> have the same keycode in X, making them unusable. After removing the
> test it forwards the events ok).
> 
> There are also problems because my sonypi input device acts both like
> a mouse and a keyboard, and the X event driver wants them to be separate.
> 
> Vojtech: should I generate two different input devices in my driver,
> a mouse like and a keyboard like device, or should the userspace be
> able to demultiplex the events ?
> 

If you want jogdial to continue generating BTN_MIDDLE and BTN_WHEEL
events then IMHO you should create 2 separate input devices - one
for jogdial and the other for FN-keys.

On the other hand I am not sure if it is handy as a ponter device -
I think scrolling is much more natural with the touchpad (but
remember I don't have the hardware) and it may be more convenient
to assign brand-new events to jogdial as well and then map it in
userspace (X) into something different, like volume control. In
this case you can continue having just one input device.

Btw, you should probably drop conditional support for input layer
and always compile it in.

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Tue, Oct 26, 2004 at 08:56:39AM -0700, Dmitry Torokhov wrote:

> If you want jogdial to continue generating BTN_MIDDLE and BTN_WHEEL
> events then IMHO you should create 2 separate input devices - one
> for jogdial and the other for FN-keys.

That's what I thought too...

> On the other hand I am not sure if it is handy as a ponter device -
> I think scrolling is much more natural with the touchpad (but
> remember I don't have the hardware)

I don't have a touchpad, just a stick. And I use the jogdial to
scroll quite often...

> and it may be more convenient
> to assign brand-new events to jogdial as well and then map it in
> userspace (X) into something different, like volume control. In
> this case you can continue having just one input device.
> 
> Btw, you should probably drop conditional support for input layer
> and always compile it in.

Is CONFIG_INPUT now a requirement for the (at least i386) kernel ?
If this is the case, I'll drop the conditional. 

Stelian.
-- 
Stelian Pop <stelian@popies.net>

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

On Tuesday 26 October 2004 01:09 pm, Stelian Pop wrote:
> > Btw, you should probably drop conditional support for input layer
> > and always compile it in.
> 
> Is CONFIG_INPUT now a requirement for the (at least i386) kernel ?
> If this is the case, I'll drop the conditional. 
> 

While it can be disabled when one selects !EMBEDDED I doubt hi/she will
be interested in sonnypi in this case :). For all practical reasons input
layer is always present.

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Dmitry Torokhov]

On Tuesday 26 October 2004 01:09 pm, Stelian Pop wrote:
> > On the other hand I am not sure if it is handy as a ponter device -
> > I think scrolling is much more natural with the touchpad (but
> > remember I don't have the hardware)
> 
> I don't have a touchpad, just a stick. And I use the jogdial to
> scroll quite often...
> 

I wonder if the best option is to always have 2 devices and make one
corrsponding to jogdial switch between mouse-like and keyboad-like
events based on module parameter.

-- 
Dmitry

Re: [PATCH 0/5] Sonypi driver model & PM changes

[Stelian Pop]

On Tue, Oct 26, 2004 at 09:56:50PM -0500, Dmitry Torokhov wrote:

> On Tuesday 26 October 2004 01:09 pm, Stelian Pop wrote:
> > > Btw, you should probably drop conditional support for input layer
> > > and always compile it in.
> > 
> > Is CONFIG_INPUT now a requirement for the (at least i386) kernel ?
> > If this is the case, I'll drop the conditional. 
> > 
> 
> While it can be disabled when one selects !EMBEDDED I doubt hi/she will
> be interested in sonnypi in this case :). For all practical reasons input
> layer is always present.

Ok. I'll remove the ifdefs and make SONYPI depend on INPUT in Kconfig.

Stelian.
-- 
Stelian Pop <stelian@popies.net>