On Sunday 30 January 2005 18:21, Dmitry Torokhov wrote:
> On Sunday 30 January 2005 03:41, Al Viro wrote:
> > On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
> > > I know. As I said, this is a problem I know about, and will be fixed. I
> > > was mainly interested whether anyone
On Sunday 30 January 2005 18:21, Dmitry Torokhov wrote:
On Sunday 30 January 2005 03:41, Al Viro wrote:
On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
I know. As I said, this is a problem I know about, and will be fixed. I
was mainly interested whether anyone sees further
On Sat, Jan 29, 2005 at 06:35:59PM -0500, Dmitry Torokhov wrote:
> On Saturday 29 January 2005 06:25, Vojtech Pavlik wrote:
> > On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
> >
> > > > I'm very sorry about the locking, but the thing grew up in times of
> > > > kernel 2.0, which didn't
On Sunday 30 January 2005 18:21, Dmitry Torokhov wrote:
> On Sunday 30 January 2005 03:41, Al Viro wrote:
> > On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
> > > I know. As I said, this is a problem I know about, and will be fixed. I
> > > was mainly interested whether anyone
On Sunday 30 January 2005 03:41, Al Viro wrote:
> On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
> > I know. As I said, this is a problem I know about, and will be fixed. I
> > was mainly interested whether anyone sees further problems in scenarios
> > which don't include device
Hi!
> > In short - raw mode in 2.6 is badly broken.
>
> I think not just that. The whole keyboard input layer needs some serious
> review. Just the complete lack of any locking is frightening, I'd really
> like to know how the input layer could become the standard. I tried to
> find a few
Hi,
On Sat, 29 Jan 2005, Vojtech Pavlik wrote:
> > That doesn't necessarilly mean we have to pack everything into a single
> > structure. E.g. we present pci boards with multiple functions as multiple
> > devices, the same can be done for input devices. More important is that
> > kernel
On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
> I know. As I said, this is a problem I know about, and will be fixed. I
> was mainly interested whether anyone sees further problems in scenarios
> which don't include device addition/removal.
>
> We already fixed this in serio,
On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote:
I know. As I said, this is a problem I know about, and will be fixed. I
was mainly interested whether anyone sees further problems in scenarios
which don't include device addition/removal.
We already fixed this in serio, and
On Saturday 29 January 2005 06:25, Vojtech Pavlik wrote:
> On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
>
> > > I'm very sorry about the locking, but the thing grew up in times of
> > > kernel 2.0, which didn't require any locking. There are a few possible
> >
> > Incorrect. You
On Saturday 29 January 2005 06:12, Vojtech Pavlik wrote:
> However, on 2.6, where you can have more than one keyboard, it'd be
> better to use the EVIOCSKEYCODE ioctl on the event device instead of the
> KDSKEYCODE ioctl on the console, as the later only changes the first
> found keyboard.
>
On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
> > I'm very sorry about the locking, but the thing grew up in times of
> > kernel 2.0, which didn't require any locking. There are a few possible
>
> Incorrect. You have blocking allocations in critical areas and they
> required locking
On Sat, Jan 29, 2005 at 01:11:08PM +0100, Roman Zippel wrote:
> > I'm very sorry about the locking, but the thing grew up in times of
> > kernel 2.0, which didn't require any locking. There are a few possible
> > races with device registration/unregistration, and it's on my list to
> > fix that,
On Fri, Jan 28, 2005 at 10:59:39PM +0100, Andries Brouwer wrote:
> On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
>
> > And, btw, raw mode in 2.6 is not badly broken. It works as it is
> > intended to. If you want the 2.4 behavior on x86, you just need to
> > specify
Hi,
On Fri, 28 Jan 2005, Vojtech Pavlik wrote:
> I'm very sorry about the locking, but the thing grew up in times of
> kernel 2.0, which didn't require any locking. There are a few possible
> races with device registration/unregistration, and it's on my list to
> fix that, however under normal
Hi,
On Fri, 28 Jan 2005, Vojtech Pavlik wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
races with device registration/unregistration, and it's on my list to
fix that, however under normal
On Fri, Jan 28, 2005 at 10:59:39PM +0100, Andries Brouwer wrote:
On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
And, btw, raw mode in 2.6 is not badly broken. It works as it is
intended to. If you want the 2.4 behavior on x86, you just need to
specify atkbd.softraw=0 on
On Sat, Jan 29, 2005 at 01:11:08PM +0100, Roman Zippel wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
races with device registration/unregistration, and it's on my list to
fix that, however
On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
Incorrect. You have blocking allocations in critical areas and they
required locking all way
On Saturday 29 January 2005 06:12, Vojtech Pavlik wrote:
However, on 2.6, where you can have more than one keyboard, it'd be
better to use the EVIOCSKEYCODE ioctl on the event device instead of the
KDSKEYCODE ioctl on the console, as the later only changes the first
found keyboard.
FWIW I
On Saturday 29 January 2005 06:25, Vojtech Pavlik wrote:
On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
Incorrect. You have blocking
On Fri, Jan 28, 2005 at 11:59:37AM +0100, Vojtech Pavlik wrote:
> I'm very sorry about the locking, but the thing grew up in times of
> kernel 2.0, which didn't require any locking. There are a few possible
Incorrect. You have blocking allocations in critical areas and they
required locking all
On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
> And, btw, raw mode in 2.6 is not badly broken. It works as it is
> intended to. If you want the 2.4 behavior on x86, you just need to
> specify "atkbd.softraw=0" on the kernel command line.
Thanks for pointing that out - I should
On Fri, Jan 28, 2005 at 01:39:08AM +0100, Roman Zippel wrote:
> On Thu, 27 Jan 2005, Andries Brouwer wrote:
>
> > In short - raw mode in 2.6 is badly broken.
And, btw, raw mode in 2.6 is not badly broken. It works as it is
intended to. If you want the 2.4 behavior on x86, you just need to
On Fri, Jan 28, 2005 at 01:39:08AM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 27 Jan 2005, Andries Brouwer wrote:
>
> > In short - raw mode in 2.6 is badly broken.
>
> I think not just that. The whole keyboard input layer needs some serious
> review. Just the complete lack of any locking is
On Fri, Jan 28, 2005 at 01:39:08AM +0100, Roman Zippel wrote:
On Thu, 27 Jan 2005, Andries Brouwer wrote:
In short - raw mode in 2.6 is badly broken.
And, btw, raw mode in 2.6 is not badly broken. It works as it is
intended to. If you want the 2.4 behavior on x86, you just need to
specify
On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
And, btw, raw mode in 2.6 is not badly broken. It works as it is
intended to. If you want the 2.4 behavior on x86, you just need to
specify atkbd.softraw=0 on the kernel command line.
Thanks for pointing that out - I should have
On Fri, Jan 28, 2005 at 11:59:37AM +0100, Vojtech Pavlik wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
Incorrect. You have blocking allocations in critical areas and they
required locking all
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
> In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
On Thu, Jan 27, 2005 at 04:16:14AM +0100, Sasa Stevanovic wrote:
> I had some problems with my laptop's onetouch keys and it eventually led me
> to keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There
> may be a bug in the file, please read below.
>
> Well, actually, when all
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wednesday 26 January 2005 22:16, Sasa Stevanovic wrote:
Hi,
I had some problems with my laptop's onetouch keys and it eventually led me to
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
a bug in the file, please read
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wednesday 26 January 2005 22:16, Sasa Stevanovic wrote:
Hi,
I had some problems with my laptop's onetouch keys and it eventually led me to
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
a bug in the file, please read
On Thu, Jan 27, 2005 at 04:16:14AM +0100, Sasa Stevanovic wrote:
I had some problems with my laptop's onetouch keys and it eventually led me
to keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There
may be a bug in the file, please read below.
Well, actually, when all
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
On Wednesday 26 January 2005 22:16, Sasa Stevanovic wrote:
> Hi,
>
> I had some problems with my laptop's onetouch keys and it eventually led me
> to
> keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
> a bug in the file, please read below.
>
> Well, actually,
Hi,
I had some problems with my laptop's onetouch keys and it eventually led me to
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
a bug in the file, please read below.
Well, actually, when all omnibook/messages/setkeycodes/hotkeys/xev/showkey etc
stuff is
Hi,
I had some problems with my laptop's onetouch keys and it eventually led me to
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
a bug in the file, please read below.
Well, actually, when all omnibook/messages/setkeycodes/hotkeys/xev/showkey etc
stuff is
On Wednesday 26 January 2005 22:16, Sasa Stevanovic wrote:
Hi,
I had some problems with my laptop's onetouch keys and it eventually led me
to
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others). There may be
a bug in the file, please read below.
Well, actually, when all
38 matches
Mail list logo
