Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Maxim Levitsky]

On Wed, 2010-09-22 at 16:06 +0200, Maxim Levitsky wrote: 
> On Wed, 2010-09-22 at 16:03 +0200, Maxim Levitsky wrote: 
> > On Wed, 2010-09-22 at 03:42 +0200, Maxim Levitsky wrote: 
> > > On Thu, 2010-09-02 at 13:46 +0300, Maxim Levitsky wrote: 
> > > > On Wed, 2010-09-01 at 06:35 -0500, Jason Wessel wrote: 
> > > > > On 09/01/2010 04:56 AM, Maxim Levitsky wrote:
> > > > > > On Thu, 2010-08-19 at 13:55 -0400, Chris Ball wrote: 
> > > > > >   
> > > > > >> Hi,
> > > > > >>
> > > > > >> Here's a patch to add support for KMS debugging to Nouveau, along the
> > > > > >> style of the previous patches for Intel¹ and Radeon².  I'm only able
> > > > > >> to test on nv50 here, so a test on nv04 would be much appreciated,
> > > > > >> and I've published instructions on how to test here³.  Thanks!
> > > > > >>
> > > > > >> - Chris.
> > > > > >>     
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I just tried that patch, but unfortunately nether with nor without it
> > > > > > kdb seems not to work.
> > > > > > It could be id10t error from my side, but I did test the kdb in the past
> > > > > > with few KMS patches, and it seemed to work.
> > > > > >
> > > > > > Now I can't even get its prompt on the console.
> > > > > >
> > > > > > This is what I do:
> > > > > >
> > > > > > echo kbd | sudo tee /sys/module/kgdboc/parameters/kgdboc
> > > > > > (also tried booting with kgdboc=kbd)
> > > > > >   
> > > > > 
> > > > > Try changing it to kgdboc=kms,kbd  or the "echo kms,kbd"
> > > > > 
> > > > > When you use only the kbd, the kms feature is not activated.
> > > > This doesn't help.
> > > > 
> > > > I am afraid that this bug isn't related to kms, but rather is generic.
> > > 
> > > I turns out that it was the NMI watchdog that I had enabled.
> > > Without it kdb works very well, including the kms support.
> > Please disregard this. kdb works with nmi watchdog now as well.
> > Probably something was fixed, maybe unrelated to it.
> > 
> > > 
> > > It would be better if you were to detect kms instead of adding an
> > > explicit param to kgdboc cmd line.
> > > 
> > > Also found out that after a debug session with Alt+SysRQ+g and X
> > > running, these keys aren't released. I had to press on all of them to
> > > make them release.
> > > It makes sense as kgdboc in that case reads directly from keyboard port.
> > And I see that kgdb actually has a code that works that around.
> > I suspect that what happens is that keys are released before X continues
> > running, and therefore it doesn't pick these events up.
> 
> However an evtest on input event running on kernel tty, still only picks
> release of the alt key.

[Dropped nouveau list, because this is offtopic there]

I pretty much got to the bottom of this.
There are 2 separate issues:


1. SysRq handler is now a input 'filter', which means that it can 'eat'
input events, so they don't show up on input bus.
It does so while sysrq key is down.
So sysrq and 'g' events never reach the kernel kbd driver and therefore
the hack to release them doesn't work.

2. The kbd_clear_keys_helper injects the keyup events alright, but it
doesn't inject SYN events, and therefore X evdev driver doesn't pick
these injected events untill next SYN event. 

This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
because now Alt+SysRQ causes a screen capture by default.
In my opinion the sysrq filter should stay.
We should just make kdb hook into atkbd and do the key release there.
This should both result in cleaner/more robust code, and make this issue disappear.
I'll look at doing that.


diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 0c6c641..7df6af5 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
 {
 	unsigned int *keycode = data;
 	input_inject_event(handle, EV_KEY, *keycode, 0);
+	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
 	return 0;
 }
 
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index ef31bb8..db1eb12 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
 	}
 
 out:
-	return sysrq_down;
+	return 0;
 }
 
 static int sysrq_connect(struct input_handler *handler,


Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Maxim Levitsky]

On Wed, 2010-09-22 at 19:07 +0200, Maxim Levitsky wrote:
> On Wed, 2010-09-22 at 16:06 +0200, Maxim Levitsky wrote: 
> > On Wed, 2010-09-22 at 16:03 +0200, Maxim Levitsky wrote: 
> > > On Wed, 2010-09-22 at 03:42 +0200, Maxim Levitsky wrote: 
> > > > On Thu, 2010-09-02 at 13:46 +0300, Maxim Levitsky wrote: 
> > > > > On Wed, 2010-09-01 at 06:35 -0500, Jason Wessel wrote: 
> > > > > > On 09/01/2010 04:56 AM, Maxim Levitsky wrote:
> > > > > > > On Thu, 2010-08-19 at 13:55 -0400, Chris Ball wrote: 
> > > > > > >   
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> Here's a patch to add support for KMS debugging to Nouveau, along the
> > > > > > >> style of the previous patches for Intel¹ and Radeon².  I'm only able
> > > > > > >> to test on nv50 here, so a test on nv04 would be much appreciated,
> > > > > > >> and I've published instructions on how to test here³.  Thanks!
> > > > > > >>
> > > > > > >> - Chris.
> > > > > > >>     
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I just tried that patch, but unfortunately nether with nor without it
> > > > > > > kdb seems not to work.
> > > > > > > It could be id10t error from my side, but I did test the kdb in the past
> > > > > > > with few KMS patches, and it seemed to work.
> > > > > > >
> > > > > > > Now I can't even get its prompt on the console.
> > > > > > >
> > > > > > > This is what I do:
> > > > > > >
> > > > > > > echo kbd | sudo tee /sys/module/kgdboc/parameters/kgdboc
> > > > > > > (also tried booting with kgdboc=kbd)
> > > > > > >   
> > > > > > 
> > > > > > Try changing it to kgdboc=kms,kbd  or the "echo kms,kbd"
> > > > > > 
> > > > > > When you use only the kbd, the kms feature is not activated.
> > > > > This doesn't help.
> > > > > 
> > > > > I am afraid that this bug isn't related to kms, but rather is generic.
> > > > 
> > > > I turns out that it was the NMI watchdog that I had enabled.
> > > > Without it kdb works very well, including the kms support.
> > > Please disregard this. kdb works with nmi watchdog now as well.
> > > Probably something was fixed, maybe unrelated to it.
> > > 
> > > > 
> > > > It would be better if you were to detect kms instead of adding an
> > > > explicit param to kgdboc cmd line.
> > > > 
> > > > Also found out that after a debug session with Alt+SysRQ+g and X
> > > > running, these keys aren't released. I had to press on all of them to
> > > > make them release.
> > > > It makes sense as kgdboc in that case reads directly from keyboard port.
> > > And I see that kgdb actually has a code that works that around.
> > > I suspect that what happens is that keys are released before X continues
> > > running, and therefore it doesn't pick these events up.
> > 
> > However an evtest on input event running on kernel tty, still only picks
> > release of the alt key.
> 
> [Dropped nouveau list, because this is offtopic there]
> 
> I pretty much got to the bottom of this.
> There are 2 separate issues:
> 
> 
> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
> input events, so they don't show up on input bus.
> It does so while sysrq key is down.
> So sysrq and 'g' events never reach the kernel kbd driver and therefore
> the hack to release them doesn't work.
> 
> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
> doesn't inject SYN events, and therefore X evdev driver doesn't pick
> these injected events untill next SYN event. 
> 
> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
> because now Alt+SysRQ causes a screen capture by default.
> In my opinion the sysrq filter should stay.
> We should just make kdb hook into atkbd and do the key release there.
> This should both result in cleaner/more robust code, and make this issue disappear.
> I'll look at doing that.
> 
> 
> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
> index 0c6c641..7df6af5 100644
> --- a/drivers/char/keyboard.c
> +++ b/drivers/char/keyboard.c
> @@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
>  {
>  	unsigned int *keycode = data;
>  	input_inject_event(handle, EV_KEY, *keycode, 0);
> +	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
>  	return 0;
>  }
>  
> diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
> index ef31bb8..db1eb12 100644
> --- a/drivers/char/sysrq.c
> +++ b/drivers/char/sysrq.c
> @@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
>  	}
>  
>  out:
> -	return sysrq_down;
> +	return 0;
>  }
>  
>  static int sysrq_connect(struct input_handler *handler,
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
Ping.

Maxim Levitsky


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Jason Wessel]

On 09/24/2010 03:50 PM, Maxim Levitsky wrote:
>   
>> [Dropped nouveau list, because this is offtopic there]
>>
>> I pretty much got to the bottom of this.
>> There are 2 separate issues:
>>
>>
>> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
>> input events, so they don't show up on input bus.
>> It does so while sysrq key is down.
>> So sysrq and 'g' events never reach the kernel kbd driver and therefore
>> the hack to release them doesn't work.
>>
>> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
>> doesn't inject SYN events, and therefore X evdev driver doesn't pick
>> these injected events untill next SYN event. 
>>
>> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
>> because now Alt+SysRQ causes a screen capture by default.
>> In my opinion the sysrq filter should stay.
>> We should just make kdb hook into atkbd and do the key release there.
>> This should both result in cleaner/more robust code, and make this issue disappear.
>> I'll look at doing that.
>>
>>
>> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
>> index 0c6c641..7df6af5 100644
>> --- a/drivers/char/keyboard.c
>> +++ b/drivers/char/keyboard.c
>> @@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
>>  {
>>  	unsigned int *keycode = data;
>>  	input_inject_event(handle, EV_KEY, *keycode, 0);
>> +	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
>>  	return 0;
>>  }
>>  
>> diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
>> index ef31bb8..db1eb12 100644
>> --- a/drivers/char/sysrq.c
>> +++ b/drivers/char/sysrq.c
>> @@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
>>  	}
>>  
>>  out:
>> -	return sysrq_down;
>> +	return 0;
>>  }
>>  
>>  static int sysrq_connect(struct input_handler *handler,
>>
>>
>> Best regards,
>> 	Maxim Levitsky
>>
>>     

Hi Maxim,

Is it the case that this patch takes care of masking the sysrq event
from user space?

Originally before it became an input filter I had a patch to the
keyboard.c to completely consume the keypress of the sysrq-g.

I have been less than successful at getting the keyboard changes
upstreamed, and I was probably going to ping AKPM, because on that front
I had not received any kind of response either (linux-input that is).

Certainly I can carry your patch in my branch until we can determine a
final upstream design.

Thanks,
Jason.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Maxim Levitsky]

On Fri, 2010-09-24 at 15:58 -0500, Jason Wessel wrote:
> On 09/24/2010 03:50 PM, Maxim Levitsky wrote:
> >   
> >> [Dropped nouveau list, because this is offtopic there]
> >>
> >> I pretty much got to the bottom of this.
> >> There are 2 separate issues:
> >>
> >>
> >> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
> >> input events, so they don't show up on input bus.
> >> It does so while sysrq key is down.
> >> So sysrq and 'g' events never reach the kernel kbd driver and therefore
> >> the hack to release them doesn't work.
> >>
> >> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
> >> doesn't inject SYN events, and therefore X evdev driver doesn't pick
> >> these injected events untill next SYN event. 
> >>
> >> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
> >> because now Alt+SysRQ causes a screen capture by default.
> >> In my opinion the sysrq filter should stay.
> >> We should just make kdb hook into atkbd and do the key release there.
> >> This should both result in cleaner/more robust code, and make this issue disappear.
> >> I'll look at doing that.
> >>
> >>
> >> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
> >> index 0c6c641..7df6af5 100644
> >> --- a/drivers/char/keyboard.c
> >> +++ b/drivers/char/keyboard.c
> >> @@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
> >>  {
> >>  	unsigned int *keycode = data;
> >>  	input_inject_event(handle, EV_KEY, *keycode, 0);
> >> +	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
> >>  	return 0;
> >>  }
> >>  
> >> diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
> >> index ef31bb8..db1eb12 100644
> >> --- a/drivers/char/sysrq.c
> >> +++ b/drivers/char/sysrq.c
> >> @@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
> >>  	}
> >>  
> >>  out:
> >> -	return sysrq_down;
> >> +	return 0;
> >>  }
> >>  
> >>  static int sysrq_connect(struct input_handler *handler,
> >>
> >>
> >> Best regards,
> >> 	Maxim Levitsky
> >>
> >>     
> 
> Hi Maxim,
> 
> Is it the case that this patch takes care of masking the sysrq event
> from user space?
> 
> Originally before it became an input filter I had a patch to the
> keyboard.c to completely consume the keypress of the sysrq-g.
> 
> I have been less than successful at getting the keyboard changes
> upstreamed, and I was probably going to ping AKPM, because on that front
> I had not received any kind of response either (linux-input that is).
> 
> Certainly I can carry your patch in my branch until we can determine a
> final upstream design.

Its an option, but bear in the mind that my 'patch' causes very
unpleasant regression.
The regression is that now Alt+SysRQ is reported to userspace and
treated as a PrintScreen which in gnome is treated as a launcher for
screenshot application.
So after you pressed it, you will end up with an army of
gnome-screenshots poping up.
So I think that tty kbd driver is wrong place for key release.

The right solution in my opinion is to make atkbd register with kgdb and
provide to it, the polling keyboard IO services, and also take care of
releasing the keys as soon as debug mode is entered or exited.

Btw, can a driver register a hook into kgdb to be executed on
enter/leave of the debug mode?
If so the atkbd driver should just do that.

I am also aware of the fact that atkbd doesn't talk to hardware
directly.
Thus 'the' proper fix is also to add a polled serio handlers, make atkbd
use them
if available and if so, register with the kgdb.

Best regards,
	Maxim Levitsky


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Dmitry Torokhov]

On Sat, Sep 25, 2010 at 02:14:32AM +0200, Maxim Levitsky wrote:
> On Fri, 2010-09-24 at 15:58 -0500, Jason Wessel wrote:
> > On 09/24/2010 03:50 PM, Maxim Levitsky wrote:
> > >   
> > >> [Dropped nouveau list, because this is offtopic there]
> > >>
> > >> I pretty much got to the bottom of this.
> > >> There are 2 separate issues:
> > >>
> > >>
> > >> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
> > >> input events, so they don't show up on input bus.
> > >> It does so while sysrq key is down.
> > >> So sysrq and 'g' events never reach the kernel kbd driver and therefore
> > >> the hack to release them doesn't work.
> > >>
> > >> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
> > >> doesn't inject SYN events, and therefore X evdev driver doesn't pick
> > >> these injected events untill next SYN event. 
> > >>
> > >> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
> > >> because now Alt+SysRQ causes a screen capture by default.
> > >> In my opinion the sysrq filter should stay.
> > >> We should just make kdb hook into atkbd and do the key release there.
> > >> This should both result in cleaner/more robust code, and make this issue disappear.
> > >> I'll look at doing that.
> > >>
> > >>
> > >> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
> > >> index 0c6c641..7df6af5 100644
> > >> --- a/drivers/char/keyboard.c
> > >> +++ b/drivers/char/keyboard.c
> > >> @@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
> > >>  {
> > >>  	unsigned int *keycode = data;
> > >>  	input_inject_event(handle, EV_KEY, *keycode, 0);
> > >> +	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
> > >>  	return 0;
> > >>  }
> > >>  
> > >> diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
> > >> index ef31bb8..db1eb12 100644
> > >> --- a/drivers/char/sysrq.c
> > >> +++ b/drivers/char/sysrq.c
> > >> @@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
> > >>  	}
> > >>  
> > >>  out:
> > >> -	return sysrq_down;
> > >> +	return 0;
> > >>  }
> > >>  
> > >>  static int sysrq_connect(struct input_handler *handler,
> > >>
> > >>
> > >> Best regards,
> > >> 	Maxim Levitsky
> > >>
> > >>     
> > 
> > Hi Maxim,
> > 
> > Is it the case that this patch takes care of masking the sysrq event
> > from user space?
> > 
> > Originally before it became an input filter I had a patch to the
> > keyboard.c to completely consume the keypress of the sysrq-g.
> > 
> > I have been less than successful at getting the keyboard changes
> > upstreamed, and I was probably going to ping AKPM, because on that front
> > I had not received any kind of response either (linux-input that is).
> > 
> > Certainly I can carry your patch in my branch until we can determine a
> > final upstream design.
> 
> Its an option, but bear in the mind that my 'patch' causes very
> unpleasant regression.
> The regression is that now Alt+SysRQ is reported to userspace and
> treated as a PrintScreen which in gnome is treated as a launcher for
> screenshot application.
> So after you pressed it, you will end up with an army of
> gnome-screenshots poping up.
> So I think that tty kbd driver is wrong place for key release.
> 

Agree.

> The right solution in my opinion is to make atkbd register with kgdb and
> provide to it, the polling keyboard IO services, and also take care of
> releasing the keys as soon as debug mode is entered or exited.

Disagree. We may support different keyboard devices with kdb or use one
keyboard (USB) to drop into debugger and then switch to atkbd...

I think we need to move Jason's code from drivers/char/keyboard.c to
drivers/char/sysrq.c and have it track keys that have been kept pressed
before entering sysrq mode and release them when leaving the mode.

We also need to teach sysrq that some handlers need resetting of the
keyboard state.

> 
> Btw, can a driver register a hook into kgdb to be executed on
> enter/leave of the debug mode?
> If so the atkbd driver should just do that.
> 
> I am also aware of the fact that atkbd doesn't talk to hardware
> directly.
> Thus 'the' proper fix is also to add a polled serio handlers, make atkbd
> use them
> if available and if so, register with the kgdb.

The issue is not that interrupts are not available but that we are
holding too many locks...

-- 
Dmitry

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Jason Wessel]

[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]

On 09/24/2010 11:08 PM, Dmitry Torokhov wrote:
> On Sat, Sep 25, 2010 at 02:14:32AM +0200, Maxim Levitsky wrote:
>   
>> On Fri, 2010-09-24 at 15:58 -0500, Jason Wessel wrote:
>>     
>>> On 09/24/2010 03:50 PM, Maxim Levitsky wrote:
>>>       
>>>>   
>>>>         
>>>>> [Dropped nouveau list, because this is offtopic there]
>>>>>
>>>>> I pretty much got to the bottom of this.
>>>>> There are 2 separate issues:
>>>>>
>>>>>
>>>>> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
>>>>> input events, so they don't show up on input bus.
>>>>> It does so while sysrq key is down.
>>>>> So sysrq and 'g' events never reach the kernel kbd driver and therefore
>>>>> the hack to release them doesn't work.
>>>>>
>>>>> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
>>>>> doesn't inject SYN events, and therefore X evdev driver doesn't pick
>>>>> these injected events untill next SYN event. 
>>>>>
>>>>> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
>>>>> because now Alt+SysRQ causes a screen capture by default.
>>>>> In my opinion the sysrq filter should stay.
>>>>> We should just make kdb hook into atkbd and do the key release there.
>>>>> This should both result in cleaner/more robust code, and make this issue disappear.
>>>>> I'll look at doing that.
>>>>>
>>>>>
>>>>> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
>>>>> index 0c6c641..7df6af5 100644
>>>>> --- a/drivers/char/keyboard.c
>>>>> +++ b/drivers/char/keyboard.c
>>>>> @@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
>>>>>  {
>>>>>  	unsigned int *keycode = data;
>>>>>  	input_inject_event(handle, EV_KEY, *keycode, 0);
>>>>> +	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
>>>>>  	return 0;
>>>>>  }
>>>>>           

So I kept this piece, in the 0002 patch which is attached.   I revised
the keyboard/input series at:

http://git.kernel.org/?p=linux/kernel/git/jwessel/linux-2.6-kgdb.git;a=shortlog;h=refs/heads/for_input

>>>>>  
>>>>> diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
>>>>> index ef31bb8..db1eb12 100644
>>>>> --- a/drivers/char/sysrq.c
>>>>> +++ b/drivers/char/sysrq.c
>>>>> @@ -601,7 +601,7 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
>>>>>  	}
>>>>>  
>>>>>  out:
>>>>> -	return sysrq_down;
>>>>> +	return 0;
>>>>>  }
>>>>>           

I took some time to look more closely at the problem, and I believe we
still want to filter out all these input events.

>   
>> The right solution in my opinion is to make atkbd register with kgdb and
>> provide to it, the polling keyboard IO services, and also take care of
>> releasing the keys as soon as debug mode is entered or exited.
>>     
>
> Disagree. We may support different keyboard devices with kdb or use one
> keyboard (USB) to drop into debugger and then switch to atkbd...
>
> I think we need to move Jason's code from drivers/char/keyboard.c to
> drivers/char/sysrq.c and have it track keys that have been kept pressed
> before entering sysrq mode and release them when leaving the mode.
>
> We also need to teach sysrq that some handlers need resetting of the
> keyboard state.
>
>   

I found the root of the problem was the low level keyboard bit mask
getting out of sync in the input layer.   Perhaps Dmitry can have a look
at the 3rd patch in the series, which addresses the problem.  

I also put these patches into kgdb-next.

I believe it fixes the problems Maxim encountered, or at least the
problems I observed independently with stuck keys and the lack of the
ability to correctly use alt-PrintScreen.

If you are willing Maxim, can you give these patches a go?

Thanks,
Jason.

[-- Attachment #2: 0001-keyboard-kgdboc-Allow-key-release-on-kernel-resume.patch --]
[-- Type: text/x-diff, Size: 4152 bytes --]

>From ed6fb201ca864e977c6a4fcf345014fd1d4ebed4 Mon Sep 17 00:00:00 2001
From: Jason Wessel <jason.wessel@windriver.com>
Date: Sun, 26 Sep 2010 06:33:36 -0500
Subject: [PATCH 1/3] keyboard,kgdboc: Allow key release on kernel resume

When using a keyboard with kdb, a hook point to free all the
keystrokes is required for resuming kernel operations.

This is mainly because there is no way to force the end user to hold
down the original keys that were pressed prior to entering kdb when
resuming the kernel.

The kgdboc driver will call kbd_dbg_clear_keys() just prior to
resuming the kernel execution which will schedule a callback to clear
any keys which were depressed prior to the entering the kernel
debugger.

CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 drivers/char/keyboard.c  |   37 +++++++++++++++++++++++++++++++++++++
 drivers/serial/kgdboc.c  |   13 +++++++++++++
 include/linux/kbd_kern.h |    1 +
 3 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index a7ca752..0c6c641 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -363,6 +363,43 @@ static void to_utf8(struct vc_data *vc, uint c)
 	}
 }
 
+#ifdef CONFIG_KDB_KEYBOARD
+static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
+{
+	unsigned int *keycode = data;
+	input_inject_event(handle, EV_KEY, *keycode, 0);
+	return 0;
+}
+
+static void kbd_clear_keys_callback(struct work_struct *dummy)
+{
+	unsigned int i, j, k;
+
+	for (i = 0; i < ARRAY_SIZE(key_down); i++) {
+		if (!key_down[i])
+			continue;
+
+		k = i * BITS_PER_LONG;
+
+		for (j = 0; j < BITS_PER_LONG; j++, k++) {
+			if (!test_bit(k, key_down))
+				continue;
+			input_handler_for_each_handle(&kbd_handler, &k,
+				      kbd_clear_keys_helper);
+		}
+	}
+}
+
+static DECLARE_WORK(kbd_clear_keys_work, kbd_clear_keys_callback);
+
+/* Called to clear any key presses after resuming the kernel. */
+void kbd_dbg_clear_keys(void)
+{
+	schedule_work(&kbd_clear_keys_work);
+}
+EXPORT_SYMBOL_GPL(kbd_dbg_clear_keys);
+#endif /* CONFIG_KDB_KEYBOARD */
+
 /*
  * Called after returning from RAW mode or when changing consoles - recompute
  * shift_down[] and shift_state from key_down[] maybe called when keymap is
diff --git a/drivers/serial/kgdboc.c b/drivers/serial/kgdboc.c
index 39f9a1a..62b6edc 100644
--- a/drivers/serial/kgdboc.c
+++ b/drivers/serial/kgdboc.c
@@ -18,6 +18,7 @@
 #include <linux/tty.h>
 #include <linux/console.h>
 #include <linux/vt_kern.h>
+#include <linux/kbd_kern.h>
 
 #define MAX_CONFIG_LEN		40
 
@@ -37,12 +38,16 @@ static struct tty_driver	*kgdb_tty_driver;
 static int			kgdb_tty_line;
 
 #ifdef CONFIG_KDB_KEYBOARD
+static bool			kgdboc_use_kbd;
+
 static int kgdboc_register_kbd(char **cptr)
 {
+	kgdboc_use_kbd = false;
 	if (strncmp(*cptr, "kbd", 3) == 0) {
 		if (kdb_poll_idx < KDB_POLL_FUNC_MAX) {
 			kdb_poll_funcs[kdb_poll_idx] = kdb_get_kbd_char;
 			kdb_poll_idx++;
+			kgdboc_use_kbd = true;
 			if (cptr[0][3] == ',')
 				*cptr += 4;
 			else
@@ -65,9 +70,16 @@ static void kgdboc_unregister_kbd(void)
 		}
 	}
 }
+
+static inline void kgdboc_clear_kbd(void)
+{
+	if (kgdboc_use_kbd)
+		kbd_dbg_clear_keys(); /* Release all pressed keys */
+}
 #else /* ! CONFIG_KDB_KEYBOARD */
 #define kgdboc_register_kbd(x) 0
 #define kgdboc_unregister_kbd()
+#define kgdboc_clear_kbd()
 #endif /* ! CONFIG_KDB_KEYBOARD */
 
 static int kgdboc_option_setup(char *opt)
@@ -231,6 +243,7 @@ static void kgdboc_post_exp_handler(void)
 		dbg_restore_graphics = 0;
 		con_debug_leave();
 	}
+	kgdboc_clear_kbd();
 }
 
 static struct kgdb_io kgdboc_io_ops = {
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index 506ad20..ae87c0a 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -144,6 +144,7 @@ struct console;
 int getkeycode(unsigned int scancode);
 int setkeycode(unsigned int scancode, unsigned int keycode);
 void compute_shiftstate(void);
+void kbd_dbg_clear_keys(void);
 
 /* defkeymap.c */
 
-- 
1.6.3.3


[-- Attachment #3: 0002-keyboard-kdb-inject-SYN-events-in-kbd_clear_keys_hel.patch --]
[-- Type: text/x-diff, Size: 1036 bytes --]

>From 43eb157cdf4213e8b7792746e7d11afec2309205 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Wed, 22 Sep 2010 10:07:05 -0700
Subject: [PATCH 2/3] keyboard,kdb: inject SYN events in kbd_clear_keys_helper

The kbd_clear_keys_helper injects the keyup events alright, but it
doesn't inject SYN events, and therefore X evdev driver doesn't pick
these injected events untill next SYN event.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 drivers/char/keyboard.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 0c6c641..7df6af5 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
 {
 	unsigned int *keycode = data;
 	input_inject_event(handle, EV_KEY, *keycode, 0);
+	input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
 	return 0;
 }
 
-- 
1.6.3.3


[-- Attachment #4: 0003-sysrq-keyboard-properly-deal-with-alt-sysrq-in-sysrq.patch --]
[-- Type: text/x-diff, Size: 3892 bytes --]

>From 33dea0e730e03814f0cd71c604185ba1c7fad51d Mon Sep 17 00:00:00 2001
From: Jason Wessel <jason.wessel@windriver.com>
Date: Tue, 5 Oct 2010 14:38:36 -0500
Subject: [PATCH 3/3] sysrq,keyboard: properly deal with alt-sysrq in sysrq input filter

This patch addresses 2 problems:

1) You should still be able to use alt-PrintScreen to capture a grab
   of a single window when the sysrq filter is active.

2) The sysrq filter should reset the low level key mask so that future
   key presses will not show up as a repeated key.  The problem was
   that when you executed alt-sysrq g and then resumed the kernel, you
   would have to press 'g' twice to get it working again.

CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 drivers/char/sysrq.c |   64 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index ef31bb8..9b97aad 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -566,6 +566,57 @@ static const unsigned char sysrq_xlate[KEY_MAX + 1] =
 static bool sysrq_down;
 static int sysrq_alt_use;
 static int sysrq_alt;
+static bool sysrq_kbd_triggered;
+
+/*
+ * This function was a copy of input_pass_event but modified to allow
+ * by-passing a specific filter, to allow for injected events without
+ * filter recursion.
+ */
+static void input_pass_event_ignore(struct input_dev *dev,
+			     unsigned int type, unsigned int code, int value,
+			     struct input_handle *ignore_handle)
+{
+	struct input_handler *handler;
+	struct input_handle *handle;
+
+	rcu_read_lock();
+
+	handle = rcu_dereference(dev->grab);
+	if (handle)
+		handle->handler->event(handle, type, code, value);
+	else {
+		bool filtered = false;
+
+		list_for_each_entry_rcu(handle, &dev->h_list, d_node) {
+			if (!handle->open || handle == ignore_handle)
+				continue;
+			handler = handle->handler;
+			if (!handler->filter) {
+				if (filtered)
+					break;
+
+				handler->event(handle, type, code, value);
+
+			} else if (handler->filter(handle, type, code, value))
+				filtered = true;
+		}
+	}
+
+	rcu_read_unlock();
+}
+
+/*
+ * Pass along alt-print_screen, if there was no sysrq processing by
+ * sending a key press down and then passing the key up event.
+ */
+static void simulate_alt_sysrq(struct input_handle *handle)
+{
+	input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 1, handle);
+	input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+	input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 0, handle);
+	input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+}
 
 static bool sysrq_filter(struct input_handle *handle, unsigned int type,
 		         unsigned int code, int value)
@@ -580,9 +631,11 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
 		if (value)
 			sysrq_alt = code;
 		else {
-			if (sysrq_down && code == sysrq_alt_use)
+			if (sysrq_down && code == sysrq_alt_use) {
 				sysrq_down = false;
-
+				if (!sysrq_kbd_triggered)
+					simulate_alt_sysrq(handle);
+			}
 			sysrq_alt = 0;
 		}
 		break;
@@ -590,13 +643,18 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
 	case KEY_SYSRQ:
 		if (value == 1 && sysrq_alt) {
 			sysrq_down = true;
+			sysrq_kbd_triggered = false;
 			sysrq_alt_use = sysrq_alt;
 		}
 		break;
 
 	default:
-		if (sysrq_down && value && value != 2)
+		if (sysrq_down && value && value != 2 && !sysrq_kbd_triggered) {
+			sysrq_kbd_triggered = true;
 			__handle_sysrq(sysrq_xlate[code], true);
+			/* Clear any handled keys from being flagged as a repeated stroke */
+			__clear_bit(code, handle->dev->key);
+		}
 		break;
 	}
 
-- 
1.6.3.3

Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.

[Maxim Levitsky]

On Tue, 2010-10-05 at 15:56 -0500, Jason Wessel wrote:
> On 09/24/2010 11:08 PM, Dmitry Torokhov wrote:
> > On Sat, Sep 25, 2010 at 02:14:32AM +0200, Maxim Levitsky wrote:
> >   
> >> On Fri, 2010-09-24 at 15:58 -0500, Jason Wessel wrote:
> >>     
> >>> On 09/24/2010 03:50 PM, Maxim Levitsky wrote:
> >>>       
> >>>>   
> >>>>         
> >>>>> [Dropped nouveau list, because this is offtopic there]
> >>>>>
> >>>>> I pretty much got to the bottom of this.
> >>>>> There are 2 separate issues:
> >>>>>
> >>>>>
> >>>>> 1. SysRq handler is now a input 'filter', which means that it can 'eat'
> >>>>> input events, so they don't show up on input bus.
> >>>>> It does so while sysrq key is down.
> >>>>> So sysrq and 'g' events never reach the kernel kbd driver and therefore
> >>>>> the hack to release them doesn't work.
> >>>>>
> >>>>> 2. The kbd_clear_keys_helper injects the keyup events alright, but it
> >>>>> doesn't inject SYN events, and therefore X evdev driver doesn't pick
> >>>>> these injected events untill next SYN event. 
> >>>>>
> >>>>> This patch makes key release work in expense of showing sysrq key to userspace, which isn't that good,
> >>>>> because now Alt+SysRQ causes a screen capture by default.
> >>>>> In my opinion the sysrq filter should stay.
> >>>>> We should just make kdb hook into atkbd and do the key release there.
> >>>>> This should both result in cleaner/more robust code, and make this issue disappear.
> >>>>> I'll look at doing that.
> >>>>>
Nope, still same problem.
Maybe more keys were released, but still
pressing Alt+SysRQ+g second time doesn't break to the debugger.

I pulled your kgdb-next branch which does contain these patches.

Best regards,
	Maxim Levitsky


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb

sysrq filter and stuck keys [ was Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.]

[Jason Wessel]

On 10/13/2010 09:34 PM, Maxim Levitsky wrote:
>
> Nope, still same problem.
> Maybe more keys were released, but still
> pressing Alt+SysRQ+g second time doesn't break to the debugger.
>
>   

Thanks for trying this out Maxim.

I have to wonder if part of the problem is the way that raw events can
propagate directly via the old keyboard interface vs the input layer.  
I had noticed something somewhat similar with an xorg.conf which
appeared to be using both the raw keyboard and the input layer for
input.  I was having all sorts of problems until I changed the xorg.conf
settings to use the input layer.  I noticed that even pressing the up
arrow in an xterm was invoking the screen shot mechanism for example.

Perhaps you can provide some more data to see if this is a similar
problem or not.

On the Fedora 13 test system I made sure the following were commented
out in the xorg.conf file.

#       InputDevice    "Keyboard0" "CoreKeyboard"

#       Option "AllowEmptyInput" "off"


This had resolved the issue at least for the system with the Intel
graphics chip and non-usb keyboard.

The next step might be to have you run with an instrumented kernel if
this is not the issue, and of course if you are willing to help further
debug this.

Thanks,
Jason.

Re: sysrq filter and stuck keys [ was Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.]

[Maxim Levitsky]

On Wed, 2010-10-20 at 11:01 -0500, Jason Wessel wrote:
> On 10/13/2010 09:34 PM, Maxim Levitsky wrote:
> >
> > Nope, still same problem.
> > Maybe more keys were released, but still
> > pressing Alt+SysRQ+g second time doesn't break to the debugger.
> >
> >   
> 
> Thanks for trying this out Maxim.
> 
> I have to wonder if part of the problem is the way that raw events can
> propagate directly via the old keyboard interface vs the input layer.  
> I had noticed something somewhat similar with an xorg.conf which
> appeared to be using both the raw keyboard and the input layer for
> input.  I was having all sorts of problems until I changed the xorg.conf
> settings to use the input layer.  I noticed that even pressing the up
> arrow in an xterm was invoking the screen shot mechanism for example.
> 
> Perhaps you can provide some more data to see if this is a similar
> problem or not.

Jardon, I already found the root cause of the problem.
First of all, note that I use xorg's evdev driver.
The in-kernel tty kbd driver is only used for virtual consoles.

The root cause is that in-kernel kbd driver beeing a client of the input
subsystem just doesn't see the sysrq keys because they are filtered,
therefore it can't release them.

The right solution is to somehow hook at the atkbd driver , tell it that
kbd tampered with its hardware, and make it release the keys.

But that is easy to say, not that easy to do...

the in-kernel kbd driver just isn't the right place for the job.

Best regards,
	Maxim Levitsky

Re: sysrq filter and stuck keys [ was Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.]

[Jason Wessel]

On 10/22/2010 09:29 PM, Maxim Levitsky wrote:
> Jason, I already found the root cause of the problem.
> First of all, note that I use xorg's evdev driver.
> The in-kernel tty kbd driver is only used for virtual consoles.
>
>   

I would like to clarify where you observed the problem.  Was it only on
the tty console in X or both places?

> The root cause is that in-kernel kbd driver beeing a client of the input
> subsystem just doesn't see the sysrq keys because they are filtered,
> therefore it can't release them.
>
>   

With the 3 patches to the input layer in kgdb-next I cannot duplicate
the problem at all.  If I remove the last patch in the series, and use
the tty console, I can definitely see the behavior you mention.  I had
added a change to the sysrq input filter (which is consumes the key
strokes) that also resets the key mask in the tty keyboard driver

Specifically in

+                       /* Clear handled keys from being flagged as a
repeated stroke */
+                       __clear_bit(code, handle->dev->key);


Else drivers that use these bits for autorepeat (like the atkbd driver)
will end up with stuck keys.

> The right solution is to somehow hook at the atkbd driver , tell it that
> kbd tampered with its hardware, and make it release the keys.
>
>   

I don't think we need to do that because the input filter should be able
to actually "properly" filter state to all its clients.  As a last
resort of course the HW state could be tracked and updated, but ideally
I'd like to avoid it.

Jason.