On Tuesday 17 July 2007 14:16, Soeren Sonnenburg wrote:
> On Tue, 2007-07-17 at 11:01 -0400, Dmitry Torokhov wrote:
> > Hi,
> >
> > On 7/17/07, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
> > >
> > > err_free_buffer:
> > > @@ -656,6 +69
Hi,
On 7/17/07, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
>
> err_free_buffer:
> @@ -656,6 +699,7 @@ static void atp_disconnect(struct usb_interface *iface)
>
>usb_set_intfdata(iface, NULL);
>if (dev) {
> + cancel_work_sync(&dev->work);
>usb_kill_u
Hi,
On 6/4/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> This is probably rather related to something in input. Some CCs added and
> original message preserved below.
>
> I think that struct input_dev passed from hidinput_disconnect() should not
> be the corrupted one, as it is dereferenced sooner
Hi Jiri,
On Wednesday 23 May 2007 19:40, Jiri Kosina wrote:
> This is pretty strange. Mouse shouldn't be claimed by hiddev. Seems like
> this mouse probably has some "interesting" HID report descriptor. Could
> you please recompile with CONFIG_HID_DEBUG enabled and send me the output?
>
It loo
Hi,
On 5/15/07, Jeremy Roberson <[EMAIL PROTECTED]> wrote:
> A very good question. Had it been, I probably would not have missed it.
>
> On Tue, 2007-05-15 at 20:38 +0200, Till Harbaum / Lists wrote:
> > Hi,
> >
> > which leads to the question: Why is the "Enable Tablets" entry not
> > inside the
Hi Tejun,
On 5/9/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Chris Rankin wrote:
> > --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> >> Okay, here's a half-assed fix. With this patch applied, if you try to
> >> unload a module while you're opening it's dev attribute, kernel will
> >> oops later when th
Hi Jan,
On Thursday 03 May 2007 17:41, Jan Kratochvil wrote:
> Hi again,
>what do you think about this? (This patch will work only against last
> gamepad rumble support patch)
>
> Thanks for your time
> Jan Kratochvil
>
> BigX button on xbox360 gamepad is surrounded by 4 green leds. T
On Thursday 03 May 2007 09:04, Jan Kratochvil wrote:
> Hi Dmitry,
>thanks for feedback. Improved version of this patch follows:
>
> It is enabled only if CONFIG_XPAD_FF is set to y.
>
> Implementation is using force feedback support for memoryless devices.
Applied with couple cosmetic change
On Saturday 05 May 2007 04:03, [EMAIL PROTECTED] wrote:
> This is a series of patches for the aiptek usb tablet driver.
>
I will take these, thanks.
--
Dmitry
-
This SF.net email is sponsored by DB2 Express
Download DB2 E
In preparation for struct class_device -> struct device input
core conversion, switch to using input_dev->dev.parent when
specifying device position in sysfs tree.
Also, do not access input_dev->private directly, use helpers.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
--
On Wednesday 02 May 2007 18:04, Greg KH wrote:
> On Wed, May 02, 2007 at 05:03:05PM +0200, Jan Kratochvil wrote:
> > The USB_DEVICE_INTERFACE_PROTOCOL will allow to match one interface
> > protocol of vendor specific device.
> > This macro is used in patch adding support for xbox360 to xpad.c
> >
On Wednesday 02 May 2007 11:05, Jan Kratochvil wrote:
>
> +config XPAD_FF
> + default n
Please don't default to anything.
>
> +#ifdef CONFIG_XPAD_FF
> +/**
> + * xpad_irq_out
> + */
Comments are welcome when they say something...
> +static void xpad_irq_out(struct urb *urb)
> +{
Hi Jan,
On Wednesday 02 May 2007 11:01, Jan Kratochvil wrote:
> This changes are expected to simplify further improves of this driver,
> We will need to add information if the driver is xbox360 device or not.
>
> Second option was to simply add u8 is_360, but what if we'll need to know
> if devic
On 4/11/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov wrote:
> >
> > *sigh* When will I learn to spell names of kernel parameters
> > correctly? It is initcall_debug, not debug_initcall :( Could you try
> > again, please?
> Here is the dmesg for
On 4/10/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov wrote:
> > Hmm, I am concerned because not only you don't have an input device created,
> > you don't even see the driver being registered with usbcore. Could you
> > please
> > try b
On Monday 09 April 2007 18:36, Helge Hafting wrote:
> On Fri, Apr 06, 2007 at 10:37:12PM -0400, Dmitry Torokhov wrote:
> > On Friday 06 April 2007 20:54, Helge Hafting wrote:
> > > I have an usb touchscreen (egalax variety) that works with
> > > the 2.6.1
On Friday 06 April 2007 20:54, Helge Hafting wrote:
> I have an usb touchscreen (egalax variety) that works with
> the 2.6.18 kernel supplied by debian.
>
> It fails when I compile 2.6.21-rc5-mm4, tuned to the machine
> in question. Unlike the debian kernel, this kernel don't use
> modules in or
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 whi
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 Wednesday 04 April 2007 21:25, Li Yu wrote:
> Jiri Kosina wrote:
> > BTW as soon as you have some presentable code, could you please send
> > it so
> > that we could see what aproach you have taken? Debating over code is
> > usualy more efficient than just ranting random ideas :)
> >
> >
> T
On Tuesday 03 April 2007 23:10, Avuton Olrich wrote:
> On 4/3/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> >
> > Could you please try 2.6.21-rc5-mm4? It has evdev locking patch that
> > I believe should fix these kind of oopses.
>
> I'd have no probl
On Thursday 29 March 2007 04:56, Jiri Kosina wrote:
> On Wed, 28 Mar 2007, Avuton Olrich wrote:
>
> > I've been having problems lately with my mouse, and I know that the
> > kernel is tainted. If that's a problem please just ignore this dump.
> > I just restarted my computer with a ck[1] kernel, w
On Tuesday 03 April 2007 17:25, René van Paassen wrote:
> -static ssize_t show_tabletProductId(struct device *dev, struct
> device_attribute *attr, char *buf)
> -{
> - struct aiptek *aiptek = dev_get_drvdata(dev);
> -
> - if (aiptek == NULL)
> + if (aiptek == NULL) {
> re
On Tuesday 03 April 2007 19:41, Pete Zaitcev wrote:
> On Tue, 03 Apr 2007 23:25:02 +0200, René van Paassen <[EMAIL PROTECTED]>
> wrote:
>
> > @@ -635,29 +760,25 @@
> >
> > TOOL_BUTTON(aiptek->curSetting.toolMode),
> >
cts as part of suspend
process and restore led state, sounds and repeat rate at resume.
Also synchronize hardware state with logical state at device
registration.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/input.c | 80 +++
On Monday 02 April 2007 21:15, Li Yu wrote:
>
> If we don't use "flip-flopping" means, the common driver and specific
> driver concepts also don't need. They are completely same driver for HID
> bus, just one without some hooks, another without.
Exactly. I am glad we are getting on the same page.
On Monday 02 April 2007 21:40, Li Yu wrote:
> May be, we need some means to change blacklist in runtime. and
> loading/unloading such driver by specific script to do it.
Please look at the new_id sysfs attribute implementation in
drivers/pci/pci-driver.c. I believe we need something similar
to dyn
On 4/2/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Mon, 2 Apr 2007, Li Yu wrote:
>
> > Hi, I do not think that using blacklist in base driver for this purpose
> > is good idea. If so, we need modify source when each new HID device
> > driver come, that's so ugly.
>
> Hi Li,
>
> well, the driver
On Sunday 01 April 2007 21:47, Li Yu wrote:
> Let me explain the internal of my current HID bus implementation. I
> think that selecting one user scene as example is good idea.
>
> Well, the user A plug a USB joystick into computer. The work processing
> of HID subsystem for this joystick is same
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 Saturday 31 March 2007 18:49, Jiri Kosina wrote:
>
> Hi,
>
> in fact I am not entirely sure that the specialized drivers hooked to the
> HID bus should be passed individual fields/usages by the generic HID
> driver. That would imply that generic HID layer would have to parse the
> received
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
> > > unconditionall
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-co
On 3/30/07, Li Yu <[EMAIL PROTECTED]> wrote:
> I think I can understand your words. but I need confirm:
>
> Before specific driver register this device, the
> fundamental/standard/common(select one by your mind:) driver had already
> attach on it likely. At this case, we should detach this hid_devi
On Thursday 29 March 2007 23:06, Li Yu wrote:
> Dmitry Torokhov wrote:
> > On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> >>
> >> The crucial thing here is that all reports but the ones that the driver
> >> registered to will be processed in a stan
On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> The crucial thing here is that all reports but the ones that the driver
> registered to will be processed in a standard way by the generic hid bus
> layer, and those reports that the driver registered to will be ignored by
> the layer, and pass
On 3/27/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Mar 2007, Dmitry Torokhov wrote:
>
> > Ideally I'd like to have all input stuff live together, but I will let
> > Jiri have usbkbd and usbmouse so people can see the stern warnings about
> > not us
On 3/27/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 27, 2007 at 12:51:18AM -0400, Dmitry Torokhov wrote:
> > On Tuesday 27 March 2007 00:29, Greg KH wrote:
> > > On Tue, Mar 27, 2007 at 12:13:06AM -0400, Dmitry Torokhov wrote:
> > > > Hi Greg,
> &g
On 3/27/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 27, 2007 at 07:12:29AM +0200, Jiri Kosina wrote:
> > On Mon, 26 Mar 2007, Greg KH wrote:
> >
> > > It is fine with me for you to do this, and you can send it to Linus if
> > > you want to, with:
> > > Signed-off-by: Greg Kroah-Hartman
On Tuesday 27 March 2007 00:29, Greg KH wrote:
> On Tue, Mar 27, 2007 at 12:13:06AM -0400, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > As I promised several month ago here is a patch series that moves
> > all USB input devices, except full HID, to drivers/input. The re
Input: move USB keyboards under drivers/input/keyboard
This will allow concentrating all input devices in one place
in {menu|x|q}config.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/input/usbkbd.c | 362
drivers
Input: move USB gamepads under drivers/input/joystick
This will allow concentrating all input devices in one place
in {menu|x|q}config.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/input/xpad.c| 428
drivers
Input: move USB touchscreens under drivers/input/touchscreen
This will allow concentrating all input devices in one place
in {menu|x|q}config.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/input/usbtouchscreen.c | 838 -
drivers
Input: remove old USB touchscreen drivers
itmtoch, mtouchusb and touchkitusb have been replaced with
composite usbtouchscreen driver and can be removed now.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/input/itmtouch.c| 271 ---
drive
Hi Greg,
As I promised several month ago here is a patch series that moves
all USB input devices, except full HID, to drivers/input. The reason
behind the move is that I am trying to have all input drivers in
the same place in menuconfig, xconfig, etc. I think it makes more
sense to have all keybo
Hi Johann,
On Saturday 17 March 2007 17:50, johann deneux wrote:
> A note about that patch: Apparently Anders Fugmann submitted a patch to use
> usb_kill_urb to linux-usb-devel for version 2.6.10.
> I don't know if this patch got lost, or if it was rejected.
Since every other USB dirver uses usb_
On 3/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> echo "Loading uhci-hcd.ko module"
> insmod /lib/uhci-hcd.ko
> echo "Loading ehci-hcd.ko module"
> insmod /lib/ehci-hcd.ko
I don't see you loading OHCI and I thought AMD boxes used that flavor.
> echo "Loading usbhid.ko module"
> ins
On 3/15/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> (added linux-usb-devel@lists.sourceforge.net to CC)
>
> On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
>
> > >> I have multiple AMD 64-bit servers in several configurations, with
> > >> several different motherboards, which fail to recognize
On Friday 09 March 2007 19:29, Pete Zaitcev wrote:
> > +/* Activity checking thread. If a sufficient period of inactivity is
> > detected,
> > + the tablet's proximity is reset. */
> > +static void activity_check(unsigned long data)
> > +{
> > + struct aiptek *aiptek = (struct aiptek *) dat
Hi Rene,
On 3/7/07, Rene van Paassen <[EMAIL PROTECTED]> wrote:
>
> /***
> + * Constants used in the sysfs files. This affords us a small size
> + * optimization, plus maintains a single point of failure (misspellings.)
> + */
>
Hi Marcel,
On 3/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Dmitry,
>
> > > This also means that the current keyboard and mouse
> > > input devices will become a HID driver.
> >
> > Are you talking about usbmouse and usbkbd?
>
> no, because if I recall correctly these are the boot mode d
On 3/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
>
> This also means that the current keyboard and mouse
> input devices will become a HID driver.
>
Are you talking about usbmouse and usbkbd?
--
Dmitry
-
Take Surveys.
On 3/5/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Mon, 5 Mar 2007, Li Yu wrote:
>
> > Under standard HID device driver development means, we need to write
> > one interrupt handler for each new HID device to report event to input
> > subsystem. However, although the most of they can not merge
On 2/23/07, Guenther Sohler <[EMAIL PROTECTED]> wrote:
>
> > > At the denoted place <==Broken Pipe ==> In the function input_event
> > > with the configuration sent from input_sync it will NOT call the event
> > > function from evdev. Thus it does not know that new data is available.
> > > Mayb
On Tuesday 13 February 2007 18:52, Jeremy Roberson wrote:
> Can you give me example syntax for using EVIOCGRAB ioctl or point me to
> the documentation? This may very well solve my problem. I wasn't aware
> that it could be issued after the device node had already been created.
>
You basically
On Tuesday 13 February 2007 16:15, Jeremy Roberson wrote:
> Well, it seems the XInput Hotplug is still going to be a bit of a mess
> for a while and some of the distributions that we are targeting have
> updated kernels but, are still using XFree86 so we want to remain as
> compatible as possible.
On 2/12/07, Jeremy Roberson <[EMAIL PROTECTED]> wrote:
> Maybe. Attached is a high level diagram of the architecture that we
> used in order to prevent the end user from having to modify the x config
> file manually whenever they add a new digitizer. With this architecture,
> the end user doesn't
On 2/12/07, Jeremy Roberson <[EMAIL PROTECTED]> wrote:
> Here is the status so far. The digitizer is recognized by the USB
> Subsystem but, there are no input handlers registered for it i.e. mouse
> or event. I'm not sure how to get an input event handler registered on
> the device. Below is th
Hi Jeremy,
On 2/10/07, Roberson, Jeremy <[EMAIL PROTECTED]> wrote:
> Here is my concern. If the HID layer is fixed to support Digitizers
> which means we would no longer need separate drivers, then how are
> we(Digitizer manufacturers) supposed to get the digitizer input before
> the X Mouse driv
On 2/7/07, Greg KH <[EMAIL PROTECTED]> wrote:
> From: Jeremy Roberson <[EMAIL PROTECTED]>
>
> Added a kernel module (gtco) to the USB Input subsystem. This kernel
> module adds support for all GTCO CalComp USB InterWrite School products.
>
Greg,
This driver uses a custom HID parser instead of g
On 1/16/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > >I started using el-cheapo usb mouse... only to find out that it breaks
> > >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> > >any usefull messages...
> > >
> > >Resume process hangs; I can still switch console
On 1/16/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I started using el-cheapo usb mouse... only to find out that it breaks
> suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> any usefull messages...
>
> Resume process hangs; I can still switch console and even type o
Hi,
Couple of comments:
On 1/2/07, Roberson, Jeremy <[EMAIL PROTECTED]> wrote:
> +
> +#include
> +#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,14))
> +/** This define is for kernels 2.6.15 and up where the input driver
> + * interface has changed
> + */
> +#define USE_INPUT_ALLOCATE
> +#include
On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 22. Dezember 2006 18:02 schrieb Dmitry Torokhov:
> > On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > right now, it merely shrinks the window.
> > > However, device_remove_f
On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 22. Dezember 2006 17:18 schrieb Dmitry Torokhov:
> > Hi,
> >
> > On 12/20/06, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > >dev = usb_get_intfdata (interface);
&
Hi,
On 12/20/06, Greg KH <[EMAIL PROTECTED]> wrote:
> From: Oliver Neukum <[EMAIL PROTECTED]>
>
> in disconnect you set the interface's private data to NULL. In your IO
> methods you unconditionally follow the pointer into never never land.
>
> Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> Si
On 12/18/06, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2006 09:36:27 -0500, "Dmitry Torokhov" <[EMAIL PROTECTED]>
> wrote:
>
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219968
> > > Synposys: Fn key on Macbook Pro stop
Hi Pete,
On 12/17/06, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> Hi, Dmitry:
>
> Do you know anything about this:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219968
> Synposys: Fn key on Macbook Pro stopped working
>
> > In kernel-2.6.18-1.2798.fc6 and earlier my Fn key worked. In
> >
On 12/6/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 6. Dezember 2006 18:28 schrieb Alan Stern:
> > In general I think it's more correct to pay attention to I/O errors and
> > try to repair them than to ignore them. After all, with any reasonable
> > device these errors do indicate a
On 12/6/06, Alan Stern <[EMAIL PROTECTED]> wrote:
>
> +static int hid_kvm_present;
> +module_param_named(kvm, hid_kvm_present, bool, 0444);
> +MODULE_PARM_DESC(kvm, "Ignore errors caused by a KVM");
> +
If we do that I think 0644 is better as it will allow users to "fix"
their keyboard wothout reb
On 12/6/06, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Dmitry Torokhov wrote:
> > Is there any reason why we can't mecanically move everything into
> > drivers/hid right now? Then Greg could simply forward all patches he
> > gets for HID your
On 12/6/06, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Marcel Holtmann wrote:
>
> > > I still have the same objection - the "simple'" code will have to be
> > > compiled into the driver instead of being a separate module and
> > > eventyally will lead to a monster-size HID module.
Hi Marcel,
On 12/6/06, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Dmitry,
>
> > > > 1. Make hidinput_disconnect_core() be more robust, it can not
> > > > break anything even failed to allocate device struct.
> > > > 2. Thanks new input device driver API, we need not the e
Hi,
On 12/6/06, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Li Yu wrote:
>
> > 1. Make hidinput_disconnect_core() be more robust, it can not
> > break anything even failed to allocate device struct.
> > 2. Thanks new input device driver API, we need not the ex
Hi,
On 11/17/06, Holger Schurig <[EMAIL PROTECTED]> wrote:
> > sorry, but i have to give you a big NACK on that one:
>
> Hehe, I actually anticipated this NACK :-)
>
> > - no more modparam: it should be per-device sysfs attributes
> > (swap_xy is basically only for touchkitusb compatibility and
>
On Friday 03 November 2006 17:33, Anssi Hannula wrote:
> Dmitry Torokhov wrote:
> > On 10/11/06, Anssi Hannula <[EMAIL PROTECTED]> wrote:
> >> Anssi Hannula wrote:
> >> > Logitech USB Receiver (046d:c101) has two interfaces. The first one
> >> > con
On 10/16/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Oct 2006, Dmitry Torokhov wrote:
>
> > I don't agree. I think that power management should be left to drivers
> > working with hardware and not be placed into input core. There will be
> > diff
On 10/16/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Oct 2006, Oliver Neukum wrote:
>
> > Am Montag, 16. Oktober 2006 16:34 schrieb Alan Stern:
> > > This intricate strategy points out a fact which should have been mentioned
> > > earlier. For HID devices that are registered with the inp
On 10/11/06, Anssi Hannula <[EMAIL PROTECTED]> wrote:
> Anssi Hannula wrote:
> > Logitech USB Receiver (046d:c101) has two interfaces. The first one
> > contains fields from HID_UP_KEYBOARD and HID_UP_LED, and the other one
> > contains fields from HID_UP_CONSUMER and HID_UP_LOGIVENDOR. This device
On 10/16/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Montag, 16. Oktober 2006 05:54 schrieben Sie:
> > > Both there's agreement in principle that PID devices should not be subject
> > > to autosuspend based on inactivity?
> >
> > Hmm, why?
>
> It was my understanding that a PID effect is star
On Friday 13 October 2006 13:16, Oliver Neukum wrote:
> Am Freitag, 13. Oktober 2006 16:33 schrieb Alan Stern:
> > On Fri, 13 Oct 2006, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > I've got a version that basically works but it has some race conditions
> > > left. Right now I do autosuspend on
On Monday 09 October 2006 18:53, Anssi Hannula wrote:
> Dmitry Torokhov wrote:
> > On Sunday 08 October 2006 14:51, Anssi Hannula wrote:
> >> (I didn't get Dmitry's original mail, so replying here)
> >>
> >> [EMAIL PROTECTED] wrote:
> >>&
On Sunday 08 October 2006 14:51, Anssi Hannula wrote:
> (I didn't get Dmitry's original mail, so replying here)
>
> [EMAIL PROTECTED] wrote:
> > Dmitry Torokhov wrote:
> >> Then there is issue with automatic loading of these sub-drivers. How
> >> do th
On Sunday 08 October 2006 04:39, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 09:20 schrieb David Brownell:
> > > If a device is always opened, as mice are, it will not be suspended.
> > > Yet they can be without any data to deliver forever.
> >
> > In 2.6.19-rc1 read Documentation/power/dev
On Sunday 08 October 2006 08:41, Zephaniah E. Hull wrote:
> 0: If you keep all the ID identical, userspace may have the capabilities
> cached. This may also cause problems, but if Dmitry or Greg calls that
> a userspace bug I'll believe them and find a workaround.
Yes, I'd consider it a bug. Tear
Hi Oliver,
On 10/6/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this exports the input layer's device mutex. This will allow a simple
> fix for the common race condition between opening an input device
> and USB suspend.
>
Hm, I was hoping to keep that mutex exclusively for input core..
On Monday 02 October 2006 19:25, Oliver Neukum wrote:
> Am Dienstag, 3. Oktober 2006 01:12 schrieb Pete Zaitcev:
>
> > I do not remember the precise chain of reasoning now, but IIRC our input
> > open methods must not return non-zero codes (even though they are defined
> > to return error codes).
On Tuesday 03 October 2006 00:32, Andrew Morton wrote:
> On Tue, 26 Sep 2006 23:37:29 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > With git-input.patch applied, my wireless USB mouse doesn't work.
>
> OK, I did a round of restesting. I haven't seen the oopses again,
> but I didn't try
On Wednesday 27 September 2006 16:06, Greg KH wrote:
> drivers/usb/input/trancevibrator.c | 159 +
>
Greg,
There is nothing in this driver that would relate to input subsystem,
can it be moved into drivers/usb/misc?
--
Dmitry
On Thursday 28 September 2006 16:37, Andrew Morton wrote:
> On Thu, 28 Sep 2006 15:56:08 -0400
> "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
>
> > On 9/28/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > Ho hum.
On Wednesday 27 September 2006 23:49, Andrew Morton wrote:
> On Wed, 27 Sep 2006 23:11:49 -0400
> Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> >
> > Works here on basically 2.6.18 + my tree.
>
> Try current-mainline + your-tree.
>
Still works... Can you ch
On Wednesday 27 September 2006 19:28, Greg KH wrote:
> On Tue, Sep 26, 2006 at 11:37:29PM -0700, Andrew Morton wrote:
> >
> > With git-input.patch applied, my wireless USB mouse doesn't work. Not sure
> > why, really - it just doesn't do any mousey things.
> >
> > On insertion I get
> >
> > son
ialize dpad_to_buttons to 0, it already is.
Oherwise you may add:
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay pan
On Thursday 07 September 2006 15:25, Daniel Ritz wrote:
> before 2.6.19, please :)
>
> [PATCH] usbtouchscreen: fix ITM data reading
>
> From: Kai Lindhom <[EMAIL PROTECTED]>
> Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
>
Acked-by: Dmitry Torokhov <[EMAIL
On Monday 04 September 2006 01:03, Adam Buchbinder wrote:
> +
> +config USB_XPAD_DPAD_MAPPING
> +bool "Map d-pad to axes for unkown xbox pads"
> +default y
> +depends on USB_XPAD
This should be a module parameter, not compile-time option.
> + *
> + * 2005-03-15 - 0.0.6 : D
On Sunday 03 September 2006 12:13, Alan Stern wrote:
> On Sat, 2 Sep 2006, Dmitry Torokhov wrote:
>
> > Greg, Alan,
> >
> > It looks like we can't win WRT USB handoff. There are some boxes that
> > need it and there are some that can't live with
On Saturday 02 September 2006 23:47, Pete Zaitcev wrote:
> On Sat, 2 Sep 2006 23:34:28 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> > It looks like we can't win WRT USB handoff. There are some boxes that
> > need it and there are some that can't live wi
.
See bugzilla #6130 (reports form Mirza Pasovic).
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/host/pci-quirks.c | 41 ++---
1 files changed, 34 insertions(+), 7 deletions(-)
Index: work/dri
On Wednesday 16 August 2006 05:14, [EMAIL PROTECTED] wrote:
>
> Greg KH wrote:
> > Go here:
> > http://vger.kernel.org/mxverify.html
> > to see how to fix this up.
> >
> >
> That test site reply me "Apparently OK!", however, I still can not
> send/receive any mail from LKML.
>
> Also, I wi
Compile-tested only
--
Dmitry
Onetouch: handle errors from input_register_device()
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/storage/onetouch.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
Index: work/drivers/usb/storage/onet
1 - 100 of 187 matches
Mail list logo
