[lkml]   [2000]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: How to read a timestamp in kernel driver code?
Hi Mike.

I can accept your other points, but your explanation here has me
completely confused. Can you please clarify?

>>> The idea is that ALT *HAS* to be pressed down anyways in
>>> order for either SYSRQ make or break to be received, so
>>> we can use the ALT break code to get out of SYSRQ mode.

>> There is one problem with that scenario: WHat happens if
>> the user tries to press ALT-SCRLK and hits the SYSRQ key
>> whilst doing so? On a correctly working keyboard, the code
>> sequence that would be presented to the kernel is...

> Ahh! This is EXACTLY the type of discussion I wanted to
> see! It helps to cover all possible scenarios. I have
> indeed written down some "whatif" charts, and tried to
> cover the situations so that SYSRQ only happens when it is
> supposed to, and any other mistakes, etc just get ignored
> gracefully. So far it works fine, but there may be times
> when it doesn't, so lets see.


>> ...and EXACTLY THE SAME sequence would show up on your
>> broken keyboard, but the sequence that your patch would
>> present to the kernel is DIFFERENT, namely...


>> ...and this needs dealing with before your patch works.

>> One solution would be to define the sequence SYSRQ SCRLK as
>> being identical to pressing SCRLK on its own, but that's
>> for you to decide.

> Evidently you haven't looked at my patch. ;o)

Guilty as charged, mainly because I'm concentrating on revision
for some exams I have to sit next week...

> My patch does NOT in ANY WAY effect the sequence of keys
> the keyboard handler sees. ALL of my changes are inside
> the code block which starts with:

> if (keycode == SYSRQ_KEY)

Where did I say otherwise?

> So if you never press SYSRQ, my code never EVER gets
> touched at all. If you do press SYSRQ, it works the same
> way that it always did - both on fixed and broken keyboards
> (when sysrq_enabled=1). The only person who would turn on
> sysrq_enabled=2, would be someone like me, who has a broken
> keyboard.

Again, where did I say otherwise?

> With sysrq_enabled=1, what happens is: The existing 2.2.14
> code toggles the variable sysrq_pressed whenever the make
> OR break code is received for SYSRQ.

> With the sysrq_enabled=2, what happens is, my code ONLY
> toggles (sysrq_pressed = !up_flag), when the SYSRQ *MAKE*
> code is received. When the BREAK code is received, it
> ignores it by just doing a "return" instead. This keeps
> sysrq_pressed in an activated state, as if the key were
> pressed and held down. Then of course we need a way to get
> OUT of SYSRQ mode, and that happens when the ALT key's
> break code is received. The code special cases everything
> so that any ALT key's break code works to clear
> sysrq_pressed.


> Any key pressed while sysrq_pressed is active, will be sent
> to the sysrq handler for processing. If the key is not
> valid, then the same thing will occur as if you pressed a
> bad key on a working keyboard without my patch.

So what you're saying is that the game I was playing the other
day, that uses Alt-ScrollLock to fire a smart bomb, will not be
able to fire the said smart bomb if played with your code enabled
when the user accidentally hits the SysRq key whilst aiming for
the ScrollLock key next to it?

> Please look at the patch to see exactly what it is doing
> first. If after looking at it, you see some scenario that
> could cause REAL TROUBLE to occur, then I certainly want to
> fix it. The current patch more or less makes the SYSRQ key
> work like a sticky key as long as ALT is held down.


> It ONLY does that however if you enable it via proc first
> with:

> echo 2 > /proc/sys/kernel/sysrq

Agreed and understood.

>>> The solution works and works well.

>> Does that include the above scenario?

> The above scenario is not possible.

Sure it is

> My patch doesn't change
> the order of keyboard make/break events hitting the code. Here
> is what happens with sysrq_enabled set to 1.

>> SYSRQ MAKE - enable's sysrq_pressed, now listening
>> for special keypress
>> SYSRQ BREAK - disable's sysrq_pressed, ignoring now
>> SCRLK MAKE - processed normally
>> SCRLK BREAK - processed normally
>> ALT BREAK - processed normally

> The above is how things happen on the existing kernel with
> ANY keyboard. With my patch, with sysrq_enabled set to 1,
> the above scenario is 100% identical.


> Here is what happens when sysrq_enabled is set to 2 with my
> patch applied:

> SYSRQ MAKE - enable's sysrq_pressed, now listening
> for special keypress
> SYSRQ BREAK - we ignore this code and return, thus keeping
> the value of sysrq_pressed the same, as if
> SYSRQ's BREAK code were never received.
> SCRLK MAKE - processed the same as if you pressed it without
> my patch applied.

So, instead of seeing ALT-SCRLK as per the first version, we now
see ALT-SYSRQ-SCRLK instead, correct ???

> SCRLK BREAK - same as make code

Thus we see ALT-SYSRQ-SCRLK released instead of ALT-SCRLK ???

> ALT BREAK - toggles sysrq_pressed *ONLY* if sysrq_pressed
> is active, then processed normally afterwards.

At which point, ALT-SYSRQ becomes inactive?

> I haven't been able to trigger any bad behavior and I've
> tried to do so a LOT on both a working keyboard and a
> broken one.

>>> HOWEVER, it changes the way that SYSRQ works from what
>>> people are used to.

>> That may not be a bad thing - did you think of that?

> No, you don't understand. It DOES NOT change the way SYSRQ
> works AT ALL IN ANY WAY WHATSOEVER on broken OR fixed
> keyboards if you enable SYSRQ with:

> echo 1 > /proc/sys/kernel/sysrq

> which is the recommended way to do so.

I understand that perfectly.

> You need to use "echo 2" to enable my behavior, and if you
> do, ALL keyboards will work with SYSRQ, however SYSRQ will
> act like a sticky key until ALT is released. It works, and
> doesn't seem to have any flaws so far.

You appear to be deliberately ignoring the scenario I pointed
out, so please advise which of the following will occur in the
given scenario:

1. (Implied by your comments) The attempted Alt-ScrollLock
where the SysRq key is accidentally hit will work fine
with `echo 1` but will silently vanish with `echo 2`.

2. (Desired behaviour) The attempted Alt-ScrollLock where
the SysRq key is accidentally hit works fine with both
`echo 1` and `echo 2` in force.

> No amount of bashing I've given it in the last day, with
> either keyboard (good or bad) has caused any undesireable
> behaviour or problems.

Have you tried any software that makes use of that oddball

Also, as I recently discovered, some keyboards don't have a gap
between the SysRq key and the F12 key, so a similar problem could
occur when trying to press Alt-F12. Is that also correctly

> If it is not accepted, I can live with it. Sure is
> annoying not being able to do SYSRQ without a patched
> kernel though, and I really don't see any other way of
> fixing it other than right inside the handle_scancode()
> function where SYSRQ is checked for.

If it deals with the desired problem without causing glitches
when trying to press adjoining keys, I for one could see no
reason to refuse it.

Best wishes from Riley.

* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.

| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.065 / U:3.696 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site