On Thu, 5 Apr 2007 16:54:17 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> > On a certain keyboard, when BIOS sets NumLock LED on, it survives the
> > takeover
> > by Linux and thus confuses users.
> >
> > Eating of an increasibly scarce quirk bit is unfortunate. We do it for
> > safety,
On 4/5/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
On a certain keyboard, when BIOS sets NumLock LED on, it survives the takeover
by Linux and thus confuses users.
Eating of an increasibly scarce quirk bit is unfortunate. We do it for safety,
given the history of nervous input devices which cras
On a certain keyboard, when BIOS sets NumLock LED on, it survives the takeover
by Linux and thus confuses users.
Eating of an increasibly scarce quirk bit is unfortunate. We do it for safety,
given the history of nervous input devices which crash if anything unusual
happens.
Signed-off-by: Pete Z
On Wed, 4 Apr 2007, Dmitry Torokhov wrote:
> Unfortunately my patch is crap. We should not be sending events down
> dev->event() until dev->open() has been called because many drivers
> start hardware from there and not ready until then. So it is HID driver
> responsibility to properly reset le
On Tuesday 03 April 2007 04:52, Jiri Kosina wrote:
> On Mon, 2 Apr 2007, Pete Zaitcev wrote:
>
> > How about this?
>
> Looks quite fine to me.
>
> But in case that Dmitry's patch "Input: add generic suspend and resume for
> uinput devices" fixes your issue too, I wouldn't merge it as it won't b
On Tue, 3 Apr 2007, Robert Marquardt wrote:
> > As this quirk is only needed once in the initialization method, we
> > could probably get rid of it and just put and explicit test for PID
> > and VID there (with apropriate comment). We can't afford wasting quirk
> > entries, as we are slowly run
Jiri Kosina wrote:
As this quirk is only needed once in the initialization method, we could
probably get rid of it and just put and explicit test for PID and VID
there (with apropriate comment). We can't afford wasting quirk entries, as
we are slowly running out of them.
Is it a problem of t
On Mon, 2 Apr 2007, Pete Zaitcev wrote:
> How about this?
Looks quite fine to me.
But in case that Dmitry's patch "Input: add generic suspend and resume for
uinput devices" fixes your issue too, I wouldn't merge it as it won't be
needed. Could you please let me know?
> @@ -947,6 +989,8 @@ sta
On Tue, 3 Apr 2007 01:04:05 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> What do you think?
The patch looks sane, although I haven't yet tested it. I'll live with
it until next quarterly update, then consider if I should take it or use
my patch for RHEL 5 and RHEL 4.
-- Pete
-
To unsubscr
On Monday 02 April 2007 19:12, Pete Zaitcev wrote:
> On Mon, 2 Apr 2007 16:48:24 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]>
> wrote:
> > On Sun, 1 Apr 2007, Pete Zaitcev wrote:
>
> > could you please change the order of the two functions, so that you
> > don't have to put the forward declarat
On Mon, 2 Apr 2007 16:48:24 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Sun, 1 Apr 2007, Pete Zaitcev wrote:
> could you please change the order of the two functions, so that you
> don't have to put the forward declaration here?
>[...]
> I'd say this is a little bit overcommented.
>
On Sun, 1 Apr 2007, Pete Zaitcev wrote:
> diff --git a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
> index ef09952..7338e81 100644
> --- a/drivers/usb/input/hid-core.c
> +++ b/drivers/usb/input/hid-core.c
> @@ -548,6 +548,28 @@ void usbhid_init_reports(struct hid_device *hid)
>
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]>
wrote:
> I think I see an issue here. Imagine that you boot a system initially with
> one keyboard connected (usb, ps/2, doesn't matter), and after some time
> you connect second USB keyboard (the NumLock is 'on' on the
Hi Pekka,
On Sunday 01 April 2007 07:49, Pekka Enberg wrote:
> On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Dell people (Stuart and Charles) complained that on some USB keyboards,
> > if BIOS enables NumLock, it stays on even after Linux has started. Since
> > we always start with NumLo
On Sun, 1 Apr 2007 14:49:59 +0300, "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Dell people (Stuart and Charles) complained that on some USB keyboards,
> > if BIOS enables NumLock, it stays on even after Linux has started. Since
> > we always
On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start with NumLock off, this confuses users. Quick double dab
at NumLock fixes it, but it'
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]>
wrote:
> On Fri, 30 Mar 2007, Pete Zaitcev wrote:
> I think I see an issue here. Imagine that you boot a system initially with
> one keyboard connected (usb, ps/2, doesn't matter), and after some time
> you connect secon
On Fri, 30 Mar 2007, Pete Zaitcev wrote:
> @@ -1328,9 +1340,18 @@ static int hid_probe(struct usb_interface *intf, const
> struct usb_device_id *id)
> return -ENODEV;
> }
>
> - if ((hid->claimed & HID_CLAIMED_INPUT))
> + if ((hid->claimed & HID_CLAIMED_INPUT)) {
>
On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
On Fri, 30 Mar 2007 14:14:20 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> > I didn't like a) layering violation, and b) that they defeat filtering
> > unconditionally. Why have any filtering then?
> >
> > Instead, I propose for USB HID
On Fri, 30 Mar 2007 14:14:20 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> > I didn't like a) layering violation, and b) that they defeat filtering
> > unconditionally. Why have any filtering then?
> >
> > Instead, I propose for USB HID driver to reset NumLock on probe. Like this:
> >
> >
Hi Pete,
On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
I didn't like a) layering violation, and b) that they defeat filtering
unconditionally. Why have any filtering then?
Instead, I propose for USB HID driver to reset NumLock on probe. Like this:
--- a/drivers/usb/input/hid-core.c
+++
This is a patch for comments only, please do not apply (at least not as-is).
I haven't got the test results yet.
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start with NumLock off, this c
22 matches
Mail list logo
