On Fri, 2007-26-10 at 12:44 -0400, Zephaniah E. Hull wrote:
> A 'filter' cares about a key or two, and might even want to remove it
> from the stream, rfkill is a good example.
The patch introduces two different features that work nicely together
but, by no means have to be used together.
1) set
On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote:
> We need a way to, at the absolute minimum, unbind the keyboard from the
> text console. The current solution sucks for things like rfkill.
>
> I'm not convinced that Ryan's fix is any better, but just saying that X
> should open the co
On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote:
> No, rfkill want to see keypresses, period. It does not care if there
> are other applications also seeing the same keypresses, it just does
> not want keypresses stolen from it.
Right. This is exactly the problem. The current grab API e
On Tue, 2007-23-10 at 09:21 -0400, Dmitry Torokhov wrote:
> Priority/filter idea is different matter. I don't think it is a giood
> solution. There will always be an "arms race", new applications would
> like to get in front of the queue all the time and it will be hard to
> manage. X should just k
On Tue, 2007-03-07 at 12:45 -0400, Zephaniah E. Hull wrote:
> We just want a more flexible approach then what we are already using[0].
>
> I'll see about writing something up when I get back to my computers[1]
> and have things set back up[2].
>
> Zephaniah E. Hull.
>
> 0: EVIOCGRAB.
> 1: The ni
There are a couple of problems that I have encountered with /dev/mem on
the 2.6.10 kernel.
The first problem is that lseek()/read() results in different data than
mmap() and reading from the mapped memory area. I've written a small
program to demonstrate the problem. I am fairly sure it is corre
6 matches
Mail list logo
