[linux-usb-devel] AIPTEK: removing input_path sysfs attribute
Hi, I think that input_path sysfs attribute must go for the following reasons: 1. It only works if evdev is compiled in or loaded before aiptek driver 2. It assumes that event devices have names /dev/input/eventX putting policy in kernel 3. It pokes to deep in the input core Now that input core is fully integrated into sysfs udev should have all the data necessary to create a permanent symlink to appropriate event device. Could you please tell me what programs if any use this attribute? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Wacom wheel reversal in 2.6.17
On Tuesday 25 July 2006 00:50, Pete Zaitcev wrote:
> Hi, Dmitry:
>
Hi Pete,
> When we pushed a 2.6.17 rebase for Fedora, one of my users complained that
> the wheel on this Wacom reversed the direction. Do you know anything
> about it? The patch has some suspicious parts:
>
> --- linux-2.6.16-1.2122_FC5/drivers/usb/input/wacom.c 2006-03-19
> 21:53:29.0 -0800
> +++ linux-2.6.17-1.2139_FC5/drivers/usb/input/wacom.c 2006-06-17
> 18:49:35.0 -0700
> @@ -374,10 +397,10 @@ static void wacom_graphire_irq(struct ur
> case 2: /* Mouse with wheel */
> input_report_key(dev, BTN_MIDDLE, data[1] &
> 0x04);
> if (wacom->features->type == WACOM_G4) {
> - rw = data[7] & 0x04 ? -(data[7] & 0x03)
> : (data[7] & 0x03);
> - input_report_rel(dev, REL_WHEEL, rw);
> + rw = data[7] & 0x04 ? (data[7] &
> 0x03)-4 : (data[7] & 0x03);
> + input_report_rel(dev, REL_WHEEL, -rw);
> } else
> - input_report_rel(dev, REL_WHEEL,
> (signed char) data[6]);
> + input_report_rel(dev, REL_WHEEL,
> -(signed char) data[6]);
This change does indeed look suspicious, we used to report wheel without
negation pretty much since dawn of times and I am not sure why it was
changed. I am CCing Ping Cheng - he should know why this change was
necessary.
> /* fall through */
>
> case 3: /* Mouse without wheel */
> @@ -406,39 +429,27 @@ static void wacom_graphire_irq(struct ur
> }
> }
>
> - input_report_key(dev, wacom->tool[0], (data[1] & 0x10) ? id : 0);
> + if (data[1] & 0x10)
> + input_report_abs(dev, ABS_MISC, id); /* report tool id */
> + else
> + input_report_abs(dev, ABS_MISC, 0); /* reset tool id */
> + input_report_key(dev, wacom->tool[0], data[1] & 0x10);
> input_sync(dev);
>
> /* send pad data */
> if (wacom->features->type == WACOM_G4) {
> - /* fist time sending pad data */
> - if (wacom->tool[1] != BTN_TOOL_FINGER) {
> - wacom->id[1] = 0;
> - wacom->serial[1] = (data[7] & 0x38) >> 2;
> - }
> - if (data[7] & 0xf8) {
> + if ((wacom->serial[1] & 0xc0) != (data[7] & 0xf8)) {
> + wacom->id[1] = 1;
> + wacom->serial[1] = (data[7] & 0xf8);
> input_report_key(dev, BTN_0, (data[7] & 0x40));
> input_report_key(dev, BTN_4, (data[7] & 0x80));
> - if (((data[7] & 0x38) >> 2) == (wacom->serial[1] &
> 0x0e))
> - /* alter REL_WHEEL value so X apps can get it */
> - wacom->serial[1] += (wacom->serial[1] & 0x01) ?
> -1 : 1;
> - else
> - wacom->serial[1] = (data[7] & 0x38 ) >> 2;
> -
> - /* don't alter the value when there is no wheel event */
> - if (wacom->serial[1] == 1)
> - wacom->serial[1] = 0;
> - rw = wacom->serial[1];
> - rw = (rw & 0x08) ? -(rw & 0x07) : (rw & 0x07);
> + rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3);
> input_report_rel(dev, REL_WHEEL, rw);
> - wacom->tool[1] = BTN_TOOL_FINGER;
> - wacom->id[1] = data[7] & 0xf8;
> - input_report_key(dev, wacom->tool[1], 0xf0);
> + input_report_key(dev, BTN_TOOL_FINGER, 0xf0);
> input_event(dev, EV_MSC, MSC_SERIAL, 0xf0);
> } else if (wacom->id[1]) {
> wacom->id[1] = 0;
> - wacom->serial[1] = 0;
> - input_report_key(dev, wacom->tool[1], 0);
> + input_report_key(dev, BTN_TOOL_FINGER, 0);
> input_event(dev, EV_MSC, MSC_SERIAL, 0xf0);
> }
> input_sync(dev);
>
> We change the userland as well, but the bug submitter narrowed it
> down to the kernel.
>
> Here's the bug:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196565
>
> The bug also mentions a regression with Volito, which seems unrelated.
> However, the code contains changes affecting Volito specifically.
>
> -- Pete
>
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourcefo
Re: [linux-usb-devel] [PATCH] usbtouchscreen: version 0.4
Hi Daniel, On Saturday 29 July 2006 18:38, Daniel Ritz wrote: > - always do usb_submit_urb(dev->irq) in probe() to work around issues > with some eGalaxe contollers Could you elaborate on the issues you are seeing? Submitting URB in ->open() basically just delays it, that's all. > +out_unregister: > + input_unregister_device(usbtouch->input); > + > out_free_buffers: > usbtouch_free_buffers(udev, usbtouch); > out_free: > input_free_device(input_dev); > kfree(usbtouch); > It is not allowed to simply call input_free_device() after calling input_unregister_device(). Either take an extra reference with input_get_device() or just add "input_dev = NULL;" after calling input_unregister_devive() - input_free_device() handles NULLs just fine. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usbtouchscreen: version 0.4
On Sunday 30 July 2006 15:26, Daniel Ritz wrote: > On Sunday 30 July 2006 20.48, Alan Stern wrote: > > On Sun, 30 Jul 2006, Daniel Ritz wrote: > > > > > there was a report from a user who saw a series of disconnect/connect > > > until X11 was started up. and of course most of the time the device > > > was disconnected when X11 fired up. the workaround he found was doing > > > cat /dev/input/event3 > /dev/null 2>&1 & > > > immediately after the touchscreen was detected. this prevented the device > > > from doing those disconnect/connects...ie. as soon as some process has the > > > event interface open the touchscreen is stable. > > > > I'm curious about this; there have been similar reports about a USB mouse > > that would repeatedly disconnect/connect itself for no apparent reason. > > I don't know if holding the event file open would make any difference, and > > in any case I don't see how it possibly could. > > well, the only difference in the touchscreen case really seems to be when > the URB is submitted... > > > > > Do you have an idea about what's really going on?" > > nope, not really...i'm still waiting for a dmesg with all debugging enabled... > i'll keep you updated... > In this case I'd rather not have this change lumped together with the rest and hold it off for now. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Should we move USB input drivers to drivers/input?
Hi, Currently we have 2 main places for input-related devices in *config - one under "Input device support" and another under "USB support". While the split made perfect sense when USB was somewhat rare and did not share the same infrastructure as the other input device it does not make sence now. User should not go to one place to enable serial version of Microtouch driver and into another place to enable USB version and so on. Do you think it is time to move everything in one place? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC/PATCH] Make usb_buffer_free() NULL-safe
Hi,
kfree() handles NULL arguments which is handy in error handling paths as one
does need to insert bunch of ifs. How about making usb_buffer_free() do the
same?
BTW, checking for !dev->bus and !dev->bus->op and !dev->bus->op->buffer_free
seems to be superfluos - we already checked that the device has bus and
bus ops and if device has buffer_alloc() then it has to have buffer_free()
as well. Should extra checks be killed?
--
Dmitry
USB: make usb_buffer_free() NULL-safe
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/core/usb.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
Index: work/drivers/usb/core/usb.c
===
--- work.orig/drivers/usb/core/usb.c
+++ work/drivers/usb/core/usb.c
@@ -751,7 +751,7 @@ void *usb_buffer_alloc (
*
* This reclaims an I/O buffer, letting it be reused. The memory must have
* been allocated using usb_buffer_alloc(), and the parameters must match
- * those provided in that allocation request.
+ * those provided in that allocation request.
*/
void usb_buffer_free (
struct usb_device *dev,
@@ -761,7 +761,9 @@ void usb_buffer_free (
)
{
if (!dev || !dev->bus || !dev->bus->op || !dev->bus->op->buffer_free)
- return;
+ return;
+ if (!addr)
+ return;
dev->bus->op->buffer_free (dev->bus, size, addr, dma);
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] onetouch - handle errors from input_register_device()
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/onetouch.c === --- work.orig/drivers/usb/storage/onetouch.c +++ work/drivers/usb/storage/onetouch.c @@ -135,6 +135,7 @@ int onetouch_connect_input(struct us_dat struct usb_onetouch *onetouch; struct input_dev *input_dev; int pipe, maxp; + int error = -ENOMEM; interface = ss->pusb_intf->cur_altsetting; @@ -211,15 +212,18 @@ int onetouch_connect_input(struct us_dat ss->suspend_resume_hook = usb_onetouch_pm_hook; #endif - input_register_device(onetouch->dev); + error = input_register_device(onetouch->dev); + if (error) + goto fail3; return 0; + fail3:usb_free_urb(onetouch->irq); fail2:usb_buffer_free(udev, ONETOUCH_PKT_LEN, onetouch->data, onetouch->data_dma); fail1:kfree(onetouch); input_free_device(input_dev); - return -ENOMEM; + return error; } void onetouch_release_input(void *onetouch_) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb: The HID Simple Driver Interface 0.3.1 (core)
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 will review CodingStyle. Sorry for uncleanly code. > Hi, Just an overall comment. I like the idea of simple plugins for HID but we somehow need to allow them be built as modules and loaded on demand so when I plug a device that needs special handling an appropriate piece will get loaded and attached to the HID driver before my device is bound to it. Built-ins are not very nice when you look from a distribution POV becuase they have to enable every option and there are qute a few of devices that need special handling. -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] Disable early handoff on Del Precision 380
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 it but latter seems to
be a minority. Unfortunately there were box kinds of reports for both
UHCI and OHCI so we can't rely on controller type to decide whether
we should perform early handoff or not. So I think sensible way is to
have DMI table of boxes that can't stomach early handoff. What do you
think?
--
Dmitry
USB: disable early handoff on Dell Precision WorkStation 380
Early handoff makes keyboard controller dead on this box.
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/drivers/usb/host/pci-quirks.c
===
--- work.orig/drivers/usb/host/pci-quirks.c
+++ work/drivers/usb/host/pci-quirks.c
@@ -334,19 +334,46 @@ static void __devinit quirk_usb_disable_
writel(0x3f, op_reg_base + EHCI_USBSTS);
iounmap(base);
+}
+
+#if defined(__i386__)
+
+#include
+
+static struct dmi_system_id no_usb_handoff_table[] __devinitdata = {
+ {
+ .ident = "Dell Precision 380",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME , "Precision WorkStation
380"),
+ },
+ },
+ { }
+};
- return;
+static inline int usb_early_handoff_enabled(void)
+{
+ return !dmi_check_system(no_usb_handoff_table);
}
+#else
+
+static inline int usb_early_handoff_enabled(void)
+{
+ return 1;
+}
+#endif /* defined(__i386__) */
static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
{
- if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
- quirk_usb_handoff_uhci(pdev);
- else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
- quirk_usb_handoff_ohci(pdev);
- else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
- quirk_usb_disable_ehci(pdev);
+ if (usb_early_handoff_enabled()) {
+ if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
+ quirk_usb_handoff_uhci(pdev);
+ else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
+ quirk_usb_handoff_ohci(pdev);
+ else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
+ quirk_usb_disable_ehci(pdev);
+ }
}
DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Disable early handoff on Del Precision 380
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 with it but latter seems to > > be a minority. Unfortunately there were box kinds of reports for both > > UHCI and OHCI so we can't rely on controller type to decide whether > > we should perform early handoff or not. So I think sensible way is to > > have DMI table of boxes that can't stomach early handoff. What do you > > think? > > I can agree with the above in theory but... > > > USB: disable early handoff on Dell Precision WorkStation 380 > > ... the 380 seems like a poor case. Did you talk to Matt Domsch > about this? In fact, we did have lots of handoff problems with the > 380 on both RHEL 3 (2.4 kernel with out-of-tree handoff patch) and > RHEL 4 (2.6.9 with more-or-less 2.6.12-level handoff). Its SMM > BIOS was badly broken, that's just how it is. But there was an > update. I remember that because I was able to redirect all bugs > related to the 380. > > I even had it marked somewhere what A-level the minimum working > BIOS on 380 is... only it's difficult to find :-) > Hmm, let's see.. Mirza, are you running with the latest BIOS? -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Disable early handoff on Del Precision 380
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 it but latter seems to > > be a minority. Unfortunately there were box kinds of reports for both > > UHCI and OHCI so we can't rely on controller type to decide whether > > we should perform early handoff or not. So I think sensible way is to > > have DMI table of boxes that can't stomach early handoff. What do you > > think? > > There doesn't appear to be anything wrong with the patch itself. You and > Pete will have to decide whether or not it's really necessary. > Judjing by the DMI data Mirza is running with BIOS A02. Since it is known that 380 needs at least A04 to function properly I don't think we will need this patch at the moment. > Did you run across any other sort of system besides the Dell 380 which > can't use the OHCI/EHCI handoff? Were there any that didn't like the UHCI > handoff? Yes, I had reports that boxes coudl not stomach both UHCI and OHCI, I'll have to dig them out... > > Were there any that haven't since been fixed by a BIOS update? > Unfortunately I don't have this kind of data. -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.17.11] xpad: dance pad support
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 : Dom's patch: d-pad handling for dance style pads
> + * - old handler mapped d-pad to axes, but some dance style games
> + *need to know when you are pressing both left+right or up+down
> + * - mapping of d-pad to buttons or axes now done
> + *on the fly via product/vendor ID's
> + * - for (known) dance pads, the mapping is d-pads to buttons, for all
> + *others, mapping defaults to axes to make things easier.
> + * - added 'Redoctane Xbox Dance Pad' USB ID's (props to helpful techs)
> + * - added 'Microsoft smaller Xbox Pad' USB ID's
> */
Please kill changelog from the source code - we have SCM to fetch this data
from.
>
> #include
> @@ -64,26 +75,44 @@
> #include
> #include
>
> -#define DRIVER_VERSION "v0.0.5"
> +#define DRIVER_VERSION "v0.0.6"
> #define DRIVER_AUTHOR "Marko Friedemann <[EMAIL PROTECTED]>"
> #define DRIVER_DESC "X-Box pad driver"
>
> +
> +
Extra whitespace?
> #define XPAD_PKT_LEN 32
>
> +/* xbox d-pads should map to buttons, as is required for DDR pads
> + but we map them to axes when possible to simplify things */
> +#define MAP_DPAD_TO_BUTTONS0
> +#define MAP_DPAD_TO_AXES 1
> +#define MAP_DPAD_DEFAULT CONFIG_USB_XPAD_DPAD_MAPPING/* from
> config */
> +
> +#define FAKE_ENTRY -2
> +
> static const struct xpad_device {
> u16 idVendor;
> u16 idProduct;
> char *name;
> +int dpad_mapping;
> } xpad_device[] = {
> -{ 0x045e, 0x0202, "Microsoft X-Box pad (US)" },
> -{ 0x045e, 0x0285, "Microsoft X-Box pad (Japan)" },
> -{ 0x05fd, 0x107a, "InterAct 'PowerPad Pro' X-Box pad (Germany)" },
> -{ 0x, 0x, "X-Box pad" }
> +{ 0x045e, 0x0202, "Microsoft X-Box pad v1 (US)",
> MAP_DPAD_TO_AXES },
Patch still wordwrapped :(
> +{ 0x045e, 0x0289, "Microsoft X-Box pad v2 (US)",
> MAP_DPAD_TO_AXES },
> +{ 0x045e, 0x0285, "Microsoft X-Box pad (Japan)",
> MAP_DPAD_TO_AXES },
> +{ 0x05fd, 0x107a, "InterAct 'PowerPad Pro' X-Box pad
> (Germany)", MAP_DPAD_TO_AXES },
> +{ 0x0c12, 0x8809, "RedOctane Xbox Dance Pad",
> MAP_DPAD_TO_BUTTONS },
> +{ 0x, 0x, "Generic X-Box pad", MAP_DPAD_DEFAULT }
> };
>
> static const signed short xpad_btn[] = {
> BTN_A, BTN_B, BTN_C, BTN_X, BTN_Y, BTN_Z,/* "analog"
> buttons */
> BTN_START, BTN_BACK, BTN_THUMBL, BTN_THUMBR,/*
> start/back/sticks */
> +FAKE_ENTRY, /* (break entry) */
> +/* only used if
> MAP_DPAD_TO_BUTTONS */
> +
> +BTN_LEFT, BTN_RIGHT,/* d-pad left,
> right */
> +BTN_0, BTN_1, /* d-pad up,
> down (XXX names??) */
> -1/*
> terminating entry */
> };
>
> @@ -92,7 +121,11 @@ static const signed short xpad_abs[] = {
> ABS_RX, ABS_RY,/* right stick */
> ABS_Z, ABS_RZ,/* triggers left/right */
> ABS_HAT0X, ABS_HAT0Y,/* digital pad */
> --1/* terminating entry */
> +FAKE_ENTRY, /* (break entry) */
> +/* only used if MAP_DPAD_TO_AXES */
> +
> +ABS_HAT0X, ABS_HAT0Y, /* d-pad axes */
> +-1 /* terminating entry */
> };
>
> static struct usb_device_id xpad_table [] = {
> @@ -111,6 +144,8 @@ struct usb_xpad {
> dma_addr_t idata_dma;
>
> char phys[65];/* physical
> device path */
> +
> +int dpad_mapping; /* whether to map d-pad
> to buttons or axes */
> };
>
> /*
> @@ -142,8 +177,15 @@ static void xpad_process_packet(struct u
> input_report_abs(dev, ABS_RZ, data[11]);
>
> /* digital pad */
> -input_report_abs(dev, ABS_HAT0X, !!(data[2] & 0x08) -
> !!(data[2] & 0x04));
> -input_report_abs(dev, ABS_HAT0Y, !!(data[2] & 0x02) -
> !!(data[2] & 0x01));
> +if (xpad->dpad_mapping == MAP_DPAD_TO_AXES) {
> +input_report_abs(dev, ABS_HAT0X, !!(data[2] & 0x08) -
> !!(data[2] & 0x04));
> +input_report_abs(dev, ABS_HAT0Y, !!(data[2] & 0x02) -
> !!(data[2] & 0x01));
> +} else if (xpad->dpad_mapping == MAP_DPAD_TO_BUTTONS) {
That second if test is not needed (there is only 2 mapping modes, right?)
> +input_report_key(dev, BTN_LEFT, (data[2] & 0x04) >> 2);
No need to shift the result. input_report_key expects 0/non-0 argument.
> // left
Comment is not
Re: [linux-usb-devel] PATCH] usbtouchscreen: fix ITM data reading
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 PROTECTED]>
Greg, will you push it through your tree?
> diff --git a/drivers/usb/input/usbtouchscreen.c
> b/drivers/usb/input/usbtouchscreen.c
> index 3b175aa..a338bf4 100644
> --- a/drivers/usb/input/usbtouchscreen.c
> +++ b/drivers/usb/input/usbtouchscreen.c
> @@ -286,7 +286,7 @@ #ifdef CONFIG_USB_TOUCHSCREEN_ITM
> static int itm_read_data(unsigned char *pkt, int *x, int *y, int *touch, int
> *press)
> {
> *x = ((pkt[0] & 0x1F) << 7) | (pkt[3] & 0x7F);
> - *x = ((pkt[1] & 0x1F) << 7) | (pkt[4] & 0x7F);
> + *y = ((pkt[1] & 0x1F) << 7) | (pkt[4] & 0x7F);
> *press = ((pkt[2] & 0x1F) << 7) | (pkt[5] & 0x7F);
> *touch = ~pkt[7] & 0x20;
>
>
--
Dmitry
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.17.11] xpad: dance pad support
On 9/21/06, Adam Buchbinder <[EMAIL PROTECTED]> wrote: > + > +static int dpad_to_buttons = 0; > +module_param(dpad_to_buttons, bool, S_IRUGO); > +MODULE_PARM_DESC(dpad_to_buttons, "Map D-PAD to buttons rather than axes for > unknown pads"); There is no need to initialize 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 panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] git-input.patch kills my USB mouse
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 > > > > sony:/home/akpm> dmesg > > [ 286.96] usb 1-1: USB disconnect, address 4 > > [ 286.96] PM: Removing info for No Bus:usbdev1.4_ep81 > > [ 286.96] PM: Removing info for usb:1-1:1.0 > > [ 286.96] PM: Removing info for No Bus:usbdev1.4_ep00 > > [ 286.96] PM: Removing info for usb:1-1 > > [ 293.948000] usb 2-1: new low speed USB device using uhci_hcd and address > > 2 > > [ 294.184000] PM: Adding info for usb:2-1 > > [ 294.184000] PM: Adding info for No Bus:usbdev2.2_ep00 > > [ 294.184000] usb 2-1: configuration #1 chosen from 1 choice > > [ 294.184000] PM: Adding info for usb:2-1:1.0 > > [ 294.236000] input: Microsoft Microsoft Wireless Optical Mouse 1.00 as > > /class/input/input7 > > [ 294.236000] input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless > > Optical Mouse 1.00] on usb-:00:1d.1-1 > > [ 294.236000] PM: Adding info for No Bus:usbdev2.2_ep81 > > > > > > It's all rather odd, because I don't think you've committed anything to > > git-input in a week. So I'd be suspecting some interaction between a > > preexisting git-input patch and some new thing which someone has added, > > possibly Greg. > > I haven't added any new USB patches in a week or so, much to the > annoyance of a number of USB developers :) > > So I really don't know what to suggest, sorry. > > Dmitry? > Works here on basically 2.6.18 + my tree. I see data coming from both /dev/input/mouse2 (and /dev/inpit/mice) and /dev/input/event3.. Andrew, do you have corresponding device node created? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] git-input.patch kills my USB mouse
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 check if you getting data from /dev/input/eventX and also load evbug module to see if reports any events. If not we'll have to check all changes ti HID driver, there wasn't many in my tree. Btw, my prism54 based card will not associate to an AP unless I specify essid "any". Have you seen such reports? Maybe my wireless tools are to blame (I am still on version 17)... -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] git-input.patch kills my USB mouse
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. Looks like there's a git-bisect in my immediate future. > > > > > > > Don't do that yet - I think I see a suspicious place in mousedev_open. > > OK. > I found it - it is in my mousedev kref changes - I forgot to grab a reference when input device is automatically opened upon creation because mixer device is already open. I will reset/update my tree tomorrow. When do you plan on next -mm? I'd like to get my tree ready for it... -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [GIT PATCH] USB patches for 2.6.18
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 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Fw: Re: 2.6.11-rc2-mm2
On Sunday 30 January 2005 16:01, Andrew Morton wrote: > > Did someone break usb input? > > > Begin forwarded message: > > Date: Sun, 30 Jan 2005 15:45:04 -0500 > From: Paul Blazejowski <[EMAIL PROTECTED]> > To: Andrew Morton <[EMAIL PROTECTED]> > Cc: LKML > Subject: Re: 2.6.11-rc2-mm2 > > > Here's another one, my USB keyboard is not functioning properly, ie. > the caps lock,scrlk and num lock lights are not on when these keys are > pressed and dmesg gets tons of spam for each key presses: > > drivers/usb/input/hid-input.c: event field not found > drivers/usb/input/hid-input.c: event field not found > drivers/usb/input/hid-input.c: event field not found > drivers/usb/input/hid-input.c: event field not found > drivers/usb/input/hid-input.c: event field not found > I this it was fixed in Vojtech tree, probably with the following patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=110702712719062&q=raw -- Dmitry --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] To add usabillity for the Maxtor Onetouch button on External Hard-drives
Hi,
On Tue, 08 Mar 2005 11:55:47 -0500, Nick Sillik <[EMAIL PROTECTED]> wrote:
> +struct usb_onetouch_wrap {
> + struct list_head list;
> + struct usb_onetouch *onetouch;
> +};
I may be wrong but I thought USB connect routines could run
simultaneously if devices are on different hubs. If so then this list
should be protected.
> +/* Attempt to connect the onetouch urb to the device */
> + /* Note: If the CONFIG_USB_STORAGE_ONETOUCH is not set */
> + /* onetouch_connect_input(us) will always return 0 */
> + switch (onetouch_connect_input(us)) {
> + case 0:
> + break;
> + default:
> + printk(KERN_WARNING USB_STORAGE
> + "Unable to allocate onetouch urb\n");
> + }
> +
Does it really need to be a switch?
--
Dmitry
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] To add usabillity for the Maxtor Onetouch button on External Hard-drives
On Wednesday 09 March 2005 00:59, Greg KH wrote:
> On Tue, Mar 08, 2005 at 08:57:06PM -0500, Nick Sillik wrote:
> > Do I need to use a spinlock, or should I just impliment a simple up/down
> > lock?
>
> Depends on how long you are going to need to hold it, and what you are
> going to be doing while holding the lock.
>
It looks like spinlock will be fine - at connect time it has to be taken
while adding to the list, at disconnect time it has to be taken while
searching list and removing element.
Btw, since there can be only one entry for a device in that list you
can rearrange code like this:
wrap = NULL;
spin_lock(&onetouch_list_lock);
list_for_each_entry(entry, &onetouch_list, list) {
if (entry->onetouch->udev == udev) {
wrap = entry;
list_del(&wrap->list);
break;
}
}
spin_unlock(&onetouch_list_lock);
if (wrap) {
onetouh = wrap->onetouch;
US_DEBUGP("device found: %s. Releasing\n", onetouch->phys);
usb_unlink_urb(onetouch->irq);
input_unregister_device(&onetouch->dev);
usb_free_urb(onetouch->irq);
...
Btw, why don't you drop that "wrap" structure and put list_head right into
usb_onetouch structure?
--
Dmitry
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] To add usabillity for the Maxtor Onetouch button on External Hard-drives
On Fri, 11 Mar 2005 15:20:30 -0500 (EST), Alan Stern
<[EMAIL PROTECTED]> wrote:
> On Fri, 11 Mar 2005, Nick Sillik wrote:
>
> > I'm resubmitting the patch with the wrap removed and the list in the
> > onetouch
> > struct. I also changed usb_unlink_urb usb_kill_urb.
>
> > +int onetouch_release_input(struct us_data *ss)
> <...>
> > + usb_unlink_urb(onetouch->irq);
>
> Should be usb_kill_urb again.
>
> > + input_unregister_device(&onetouch->dev);
> > + usb_free_urb(onetouch->irq);
> > + usb_buffer_free(onetouch->udev, ONETOUCH_PKT_LEN,
> > + onetouch->data, onetouch->data_dma);
> > + kfree(onetouch);
>
> I'm not too familiar with the input layer. Can't this code run while a
> user still has the input device file open? If it does, what will happen
> when the user later closes the device file and onetouch_close tries to
> dereference a pointer to deallocated memory?
It is OK, input layer will not try to call close on a device taht is
marked dead.
> In usb.c:usb_stor_release_resources():
> > +/* Attempt to connect the onetouch urb to the device */
> > + /* Note: If the CONFIG_USB_STORAGE_ONETOUCH is not set */
> > + /* onetouch_connect_input(us) will always return 0 */
> > + switch (onetouch_connect_input(us)) {
> > + case 0:
> > + break;
> > + default:
> > + printk(KERN_WARNING USB_STORAGE
> > + "Unable to allocate onetouch urb\n");
> > + }
> > +
> > /* Kill the control thread. The SCSI host must already have been
> >* removed so it won't try to queue any more commands.
> >*/
>
> Looks like you cut & pasted instead of writing the correct code here.
>
May we have it converted to "if", pretty please? I don't think it will
ever act on return code from onetouch_connect_input.
--
Dmitry
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [OOPS/HACK] atmel_cs and the latest changes in sysfs/symlink.c
On Friday 23 April 2004 01:03 pm, Greg KH wrote: > On Fri, Apr 23, 2004 at 10:19:53AM -0700, Greg KH wrote: > > On Fri, Apr 23, 2004 at 08:31:11AM -0700, Greg KH wrote: > > > > > > No, we need to oops, as that's a real bug. Can you post the whole oops > > > that was generated with this usb problem? I can't seem to duplicate > > > this here. > > > > Nevermind I dug up a device here that causes this problem. I'll track > > it down... > > Ok, here's a patch that fixes it for me. I was waiting for a good > reason to finally get rid of this fake usb_interface structure, and now > I have it :) > Yes, it does fix it for me, thanks a lot! Now if somebody could fix the following oops... Unable to handle kernel paging request at virtual address e1b1a120 printing eip: e1b1504a *pde = 1fe1d067 *pte = Oops: 0002 [#1] PREEMPT CPU:0 EIP:0060:[]Tainted: P EFLAGS: 00010246 (2.6.6-rc2) EIP is at hiddev_cleanup+0x2a/0x40 [usbhid] eax: 0060 ebx: d7215640 ecx: edx: e18728f4 esi: e1b19b80 edi: dfe30800 ebp: df2bfe50 esp: df2bfe44 ds: 007b es: 007b ss: 0068 Process khubd (pid: 400, threadinfo=df2be000 task=df3a5230) Stack: d7922680 e1b19c7c d3e8e000 df2bfe64 e1b14ac8 d7215640 e1b19b80 d7922680 df2bfe80 e1859106 d7922680 d7922680 d44f9da0 d7922690 e1b19ba0 df2bfe98 c0210bc6 d7922690 d79226b8 d7922690 dfe308cc df2bfeb0 c0210d03 d7922690 Call Trace: [] hid_disconnect+0xb8/0xe0 [usbhid] [] usb_unbind_interface+0x76/0x80 [usbcore] [] device_release_driver+0x66/0x70 [] bus_remove_device+0x53/0xa0 [] device_del+0x5d/0xa0 [] device_unregister+0x14/0x30 [] usb_disable_device+0x70/0xb0 [usbcore] [] usb_disconnect+0xa6/0x100 [usbcore] [] usb_disconnect+0xe8/0x100 [usbcore] [] hub_port_connect_change+0x28f/0x2a0 [usbcore] [] hub_port_status+0x41/0xb0 [usbcore] [] hub_events+0x343/0x3b0 [usbcore] [] hub_thread+0x35/0xf0 [usbcore] [] default_wake_function+0x0/0x20 [] hub_thread+0x0/0xf0 [usbcore] [] kernel_thread_helper+0x5/0x10 -- Dmitry --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [OOPS/HACK] atmel_cs and the latest changes in sysfs/symlink.c
On Saturday 24 April 2004 09:49 pm, Greg KH wrote: > On Sat, Apr 24, 2004 at 01:44:04AM -0500, Dmitry Torokhov wrote: > > > Yes, it does fix it for me, thanks a lot! > > Now if somebody could fix the following oops... > > When does that oops happen? With my patch applied? Are you yanking out > a device that currently has a userspace progam attached to it? What > kind of device is it? > > Hm, this might solve the problem, can you try the patch below? It's on > top of my previous patch. > (removed some recipients from the CC list..) No, I am still getting the oops.. hmm.. it seems a little bit different, but still in the hiddev. I investigated further and the oops only happens if I yank a HID device connected to an USB hub or if I yank entire hub with a HID device connected to it. Tried with APC UPS and MS Intellimouse Explorer. If they are connected directly to the laptop's ports everything is fine, also other devices (USB printer for example) handle hub disconnection just fine. It does not matter if I have device open or closed for oops to happen. And, for the record, oops itself: Apr 25 16:18:40 core kernel: usb 1-1: USB disconnect, address 3 Apr 25 16:18:40 core kernel: Unable to handle kernel paging request at virtual address e19a9120 Apr 25 16:18:40 core kernel: printing eip: Apr 25 16:18:40 core kernel: e19a4031 Apr 25 16:18:40 core kernel: *pde = 1fe1d067 Apr 25 16:18:40 core kernel: *pte = Apr 25 16:18:40 core kernel: Oops: 0002 [#1] Apr 25 16:18:40 core kernel: PREEMPT Apr 25 16:18:40 core kernel: CPU:0 Apr 25 16:18:40 core kernel: EIP:0060:[]Not tainted Apr 25 16:18:40 core kernel: EFLAGS: 00010246 (2.6.6-rc2) Apr 25 16:18:40 core kernel: EIP is at hiddev_cleanup+0x11/0x40 [usbhid] Apr 25 16:18:40 core kernel: eax: 0060 ebx: dd0c4760 ecx: edx: de2b7b48 Apr 25 16:18:40 core kernel: esi: e19a8b80 edi: c1565400 ebp: de025e78 esp: de025e6c Apr 25 16:18:41 core kernel: ds: 007b es: 007b ss: 0068 Apr 25 16:18:41 core kernel: Process khubd (pid: 400, threadinfo=de024000 task=ddbd0d30) Apr 25 16:18:41 core kernel: Stack: de025e78 e185e5ef ddd3 de025e8c e19a3ac8 dd0c4760 e19a8b80 dfc1d4c0 Apr 25 16:18:41 core kernel:de025ea8 e1859106 dfc1d4c0 dfc1d4c0 dcfe33e0 dfc1d4d0 e19a8ba0 de025ec0 Apr 25 16:18:41 core kernel:c0210bc6 dfc1d4d0 dfc1d4f8 dfc1d4d0 c15654cc de025ed8 c0210d03 dfc1d4d0 Apr 25 16:18:41 core kernel: Call Trace: Apr 25 16:18:41 core kernel: [] usb_unlink_urb+0x3f/0x50 [usbcore] Apr 25 16:18:41 core kernel: [] hid_disconnect+0xb8/0xe0 [usbhid] Apr 25 16:18:41 core kernel: [] usb_unbind_interface+0x76/0x80 [usbcore] Apr 25 16:18:41 core kernel: [] device_release_driver+0x66/0x70 Apr 25 16:18:41 core kernel: [] bus_remove_device+0x53/0xa0 Apr 25 16:18:41 core kernel: [] device_del+0x5d/0xa0 Apr 25 16:18:41 core kernel: [] device_unregister+0x14/0x30 Apr 25 16:18:41 core kernel: [] usb_disable_device+0x70/0xb0 [usbcore] Apr 25 16:18:41 core kernel: [] usb_disconnect+0xa6/0x100 [usbcore] Apr 25 16:18:41 core kernel: [] hub_port_connect_change+0x28f/0x2a0 [usbcore] Apr 25 16:18:41 core kernel: [] hub_port_status+0x41/0xb0 [usbcore] Apr 25 16:18:41 core kernel: [] hub_events+0x343/0x3b0 [usbcore] Apr 25 16:18:41 core kernel: [] hub_thread+0x35/0xf0 [usbcore] Apr 25 16:18:41 core kernel: [] default_wake_function+0x0/0x20 Apr 25 16:18:41 core kernel: [] hub_thread+0x0/0xf0 [usbcore] Apr 25 16:18:41 core kernel: [] kernel_thread_helper+0x5/0x10 Apr 25 16:18:41 core kernel: Apr 25 16:18:41 core kernel: Code: 89 0c 85 a0 8f 9a e1 c7 44 24 04 7c 8c 9a e1 8b 43 14 8b 80 -- Dmitry --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [OOPS/HACK] atmel_cs and the latest changes in sysfs/symlink.c
On Tuesday 04 May 2004 04:04 pm, Greg KH wrote: > On Sun, Apr 25, 2004 at 04:48:07PM -0500, Dmitry Torokhov wrote: > > > > No, I am still getting the oops.. hmm.. it seems a little bit different, > > but still in the hiddev. I investigated further and the oops only happens > > if I yank a HID device connected to an USB hub or if I yank entire hub with > > a HID device connected to it. Tried with APC UPS and MS Intellimouse > > Explorer. If they are connected directly to the laptop's ports everything is > > fine, also other devices (USB printer for example) handle hub disconnection > > just fine. It does not matter if I have device open or closed for oops to > > happen. And, for the record, oops itself: > > Are you still getting this in the 2.6.6-rc3 kernel? > > How about the latest -mm release? > With tonight's bk pull + USB patch from 2.6.6-rc3-mm1 I am still getting the following oops when pulling a HID device out of a hub: usb 1-1: USB disconnect, address 2 usb 1-2: USB disconnect, address 3 usb 1-2.3: USB disconnect, address 4 Unable to handle kernel paging request at virtual address e19f6140 printing eip: e19f1037 *pde = 1fe1e067 *pte = Oops: 0002 [#1] PREEMPT CPU:0 EIP:0060:[]Not tainted EFLAGS: 00010246 (2.6.6-rc3) EIP is at hiddev_cleanup+0x17/0x50 [usbhid] eax: 0060 ebx: d8de4f9c ecx: edx: d7d6cb10 esi: e19f5ba0 edi: df905400 ebp: df69be54 esp: df69be48 ds: 007b es: 007b ss: 0068 Process khubd (pid: 532, threadinfo=df69a000 task=dfa35730) Stack: df69be54 e185db5f d8c3 df69be68 e19f0ac8 d8de4f9c e19f5ba0 dfd718b4 df69be84 e1858106 dfd718b4 dfd718b4 d7e64660 dfd718c4 e19f5bc0 df69be9c c0210a66 dfd718c4 dfd718ec dfd718c4 df9054cc df69beb4 c0210ba3 dfd718c4 Call Trace: [] usb_unlink_urb+0x3f/0x50 [usbcore] [] hid_disconnect+0xb8/0xe0 [usbhid] [] usb_unbind_interface+0x76/0x80 [usbcore] [] device_release_driver+0x66/0x70 [] bus_remove_device+0x53/0xa0 [] device_del+0x5d/0xa0 [] device_unregister+0x14/0x30 [] usb_disable_device+0x6f/0xc0 [usbcore] [] usb_disconnect+0xa6/0x100 [usbcore] [] usb_disconnect+0xe8/0x100 [usbcore] [] hub_port_connect_change+0x2a7/0x2e0 [usbcore] [] hub_events+0x343/0x3b0 [usbcore] [] hub_thread+0x35/0xf0 [usbcore] [] default_wake_function+0x0/0x20 [] hub_thread+0x0/0xf0 [usbcore] [] kernel_thread_helper+0x5/0x10 Code: 89 0c 85 c0 5f 9f e1 c7 44 24 04 9c 5c 9f e1 8b 43 10 8b 80 If HID device connected directly to laptop's USB port I can yank it without any trouble. -- Dmitry --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite School products
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 going through HID driver, I wonder if it is the best solution... -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite School products
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 driver takes it? Please forgive my ignorance, but I'm still > learning. > Do you mean "how my X driver can consume all events without levaing anything to the default X mouse driver feeding off /dev/input/mice"? Well, mousedev multiplexor is evil and as soon as X drivers start support hotplugging of input devices we will kill it. But for now your X digitizer driver can do EVIOCGRAB ioctl ensuring that it will be the only recepient of events produced by the device in question. Does this answer your question? -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite School products
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 the output of lsusb. > You mean that current HID driver does not attach to the device, right? I am CCing Jiri Kosina, HID maintainer > Bus 001 Device 008: ID 078c:0401 > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x078c > idProduct 0x0401 > bcdDevice1.00 > iManufacturer 1 GTCO/CalComp > iProduct2 Digitizer > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: >bLength 9 >bDescriptorType 2 >wTotalLength 34 >bNumInterfaces 1 >bConfigurationValue 1 >iConfiguration 0 >bmAttributes 0x40 > (Missing must-be-set bit!) > Self Powered >MaxPower2mA >Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Devices > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 3 TABLET BQ1.4 >HID Device Descriptor: > bLength 9 > bDescriptorType33 > bcdHID 1.00 > bCountryCode0 Not supported > bNumDescriptors 1 > bDescriptorType34 Report > wDescriptorLength 147 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: >bLength 7 >bDescriptorType 5 >bEndpointAddress 0x81 EP 1 IN >bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data >wMaxPacketSize 0x0008 1x 8 bytes >bInterval 5 > Device Status: 0x0001 > Self Powered > > > Regarding the IPanel. Both a mouse and input event handler are > registered to it when it is plugged in. Instead of blacklisting it and > using a separate driver, is there a way to unregister the mouse handler > and just leave the general event handler? > > Please let me know if I should be working with someone else on these > issues, I don't want to bug anyone. > > Thanks, > > On Fri, 2007-02-09 at 08:46 -0800, Greg KH wrote: > > On Thu, Feb 08, 2007 at 09:37:47PM -0700, Roberson, Jeremy wrote: > > > The HID driver doesn't parse Digitizer data properly which, is why > > > Wacom, etc requires custom drivers for their digitizers. Same for our > > > digitizers. As far as I know, Digitizers have never been parsed > > > properly by the HID Driver. I can get more details on what is not > > > parsed properly by the HID Driver but, it will take some time. > > > > It would be good to learn more about this, so possibly we can fix the > > HID layer so that it works for everyone and these drivers can go away. > > > > thanks, > > > > greg k-h > -- > Jeremy Roberson > Software Engineer > GTCO CalComp > > "Do not go gentle into that good night, > Old age should burn and rave at the > close of the day; Rage, rage against the > dying of the light." > - Dylan Thomas > > > > Note: The information contained within this electronic transmission is > intended by Interwrite Learning for the use of the named individual or > entity to which it is directed and contains confidential and/or > privileged information. It is not intended for transmission or receipt > by anyone other than the named addressee or entity. It should not be > forwarded or copied to any unauthorized persons. If you have received > this is error, please remove it from your system, without copying or > forwarding it and notify the sender by return email. Thank you. > -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite School products
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 need to know what device node the digitizer is > attached to and the X config file doesn't need to be constantly > modified. So, as far as the end user is concerned the Digitizers are > hot plug-able. > > So, to my question. In order to use EVIOCGRAB ioctl in my X driver, > don't I have to already know the device node that the digitizer is > attached to? > Yes, you would need a device node. If X would support hotplug then different input drivers could query new device ID (struct inpuit_id) and capabilities and make decision whether they want to attach to it and whether they want exclusive access (EVIOCSGRAB). In absense of hotplug in X (is it still absent btw?) your device manager will need to perform the same functions. How does current version of your device manager know what device nodes to attach to? -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite Scho ol products
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. > > > Our current X driver doesn't care what device node it's attached to, in > fact it's attached to /dev/null. When the X Driver is loaded, it > allocates shared memory that it uses to communicate with our Device > Manager. > > Our USB Devices are blacklisted so that we can use our own USB kernel > module to create and manage the device node. > The Device Mgr listens for a signal that a new device node has been > created in /dev/input/ and then we enumerate it and check to see whether > it's one of our boards etc. As low level input events are generated by > our boards, the Device Manager retrieves them and then passes them onto > our X Driver via the shared memory which, in tern formats the low level > input events into XInput events and then posts them on the XInput event > queue. > > Not sure if this answers your question or not. If not, please let me > know. Yes it does. So in your case it would be Device Manager who issues EVIOCGRAB ioctl on the device node once you enumerated it. This will stop X mouse driver from also getting events while still allowing DM to process them and convert to XInput. -- Dmitry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 59/70] USB Input: Added kernel module to support all GTCO CalComp USB InterWrite Sc hool products
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 do: ret = ioctl(fd, EVIOCGRAB, 1); to "grab" device for exclusive access and ret = ioctl(fd, EVIOCGRAB, 0); to release it after you are done with it. fd is a file descriptor you get when you open /dev/input/eventX. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Still Problems with USB Remote control
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. > > > Maybe hid_input_report should call another function but input_sync > > > instead ... > > If you look at the function stack i described earlier, you see that there is > the function 'input_sync' which calls the function 'input_event'. > Input sync gets the parametes from the function call in "input_sync" but > with this parameters submitted, "input_event" will NEVER call the > event function of the evdev device. > In input lungua evdev is not a device but a handler (interface) so input_sync should definitely reach evdev_event throug this piece of code at the end of input_event(): list_for_each_entry(...) if (handle->open) handle->handler->event(...) -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
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 into > > mainstream kernel tree, they have only some extended keys, e.g. many > > remote controllers. I think it seem break a fly on the wheel, which > > write one new interrupt handler for this reason. > > This paragraph I don't seem to understand. Either the device is claimed by > hid-input (*), and then when the device is behaving more-or-less > correctly, hid-input handles the usages sent in reports and maps them > properly to input events. New mapping can be quite trivially added to > hid-input. > We are running out if quirks and we can't continue in this fashion so Li tried to provide mechanism to augment default HID behaviour for sepcific devices. However I don't think we want this particular implementation - it firrces sub-drivers to be compiled into HID driver which may grow indefinitely. If we define HID "bus" allowing drivers to bind on VID:PID and provide default library module for parsing HID reports and providing access to HID transports (USB/BT) then writing tiny drivers adjusting just a part of hid_input_event and relying on default implemenattaion where it makes sense will become a breeze. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
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. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
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 drivers and > actually not used at all in any modern distribution. > > For me the task of converting HID reports into input events shouldn't be > actually the job of the HID core layer. My understanding is that the HID > core should support multiple transport layers. This is currently > achieved through the hid_device abstraction and used by the USB and by > the Bluetooth subsystem. This is the lower interface to HID. On the > upper interface I like to see a driver like interface. So we can > register specific drivers that can handle specific use cases or vendor > specific reports. For standard keyboard and mouse reports we however > should have a standard driver that can handle most of them. > > For identification we actually do have the bus type, vendor id and > product id available. We also can register drivers for specific report > ids or usages. > > I do like the HID simple driver idea, but it is not a simple driver, it > should be a generic driver interface. > Ah, OK. Then we are in complete agreement ;) -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.20 1/1] usb/input updated aiptek tablet driver
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.)
> + */
> +static char *pStylus = "stylus";
> +static char *pMouse = "mouse";
> +static char *pEither = "either";
> +static char *pUnknown = "unknown";
> +static char *pAbsolute = "absolute";
> +static char *pRelative = "relative";
> +static char *pEraser = "eraser";
> +static char *pPen = "pen";
> +static char *pPencil = "pencil";
> +static char *pBrush = "brush";
> +static char *pAirbrush = "airbrush";
> +static char *pLens = "lens";
> +static char *pDisable = "disable";
> +static char *pUpper = "upper";
> +static char *pLower = "lower";
> +static char *pLeft = "left";
> +static char *pRight = "right";
> +static char *pMiddle = "middle";
> +
Does not this waste 4 bytes per string as opposed to static char[]? Or
does it only matter with __initdata?
> @@ -1034,8 +1185,7 @@
>if (aiptek == NULL)
>return 0;
>
> - return snprintf(buf, PAGE_SIZE, "0x%04x\n",
> - aiptek->inputdev->id.product);
> + return snprintf(buf, PAGE_SIZE, pHex, aiptek->inputdev->id.product);
> }
I believe input core already exports all these IDs, so I'd rather have
these attributes removed.
> + /* Register the tablet as an Input Device
> +*/
> + input_register_device(aiptek->inputdev);
> +
I'd appreciate if you add error handling here.
> + /* We now will look for the evdev device which is mapped to
> +* the tablet. The partial name is kept in the link list of
> +* input_handles associated with this input device.
> +* What identifies an evdev input_handler is that it begins
> +* with 'event', continues with a digit, and that in turn
> +* is mapped to /{devfs}/input/eventN.
> +*/
> + inputdev = aiptek->inputdev;
> + list_for_each_safe(node, next, &inputdev->h_list) {
> + inputhandle = to_handle(node);
> + if (strncmp(inputhandle->name, "event", 5) == 0) {
> + strcpy(aiptek->features.inputPath,
> + inputhandle->name);
> + break;
> + }
> + }
And get rid of this part cmpletely. It does not even work if evdev is
not loaded before aiptek.
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.20 1/1] usb/input updated aiptek tablet driver
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 *) data;
> > +
> > + /* This timer is set *after* handling input for the table, and
> > + cleared *before* handling it. Am guessing that we never run
> > + concurrently the module code. */
> > +
> > + /* info("aiptek: timeout proximity\n"); */
> > +
> > + /* apparently over-due. Reset the misc key, no tool, no proximity */
> > + input_report_abs(aiptek->inputdev, ABS_MISC, 0);
> > + input_sync(aiptek->inputdev);
> > +}
>
> This concerns me a bit. I am not 100% sure that input_sync and friends
> are safe to run from several CPUs. Usually, nobody is bitten by this,
> because they are delivered from a single IRQ. If you start doing this
> from a timer, it's not longer true. Dmitry must bless this practice
> (cc-ed). Perhas you want a spinlock here.
>
I want to fix locking in input handlers so concurrent execution of
->event() methods is not an issue. However there will be a question
of correctness of the sequence in what events are delivered so some
kind of locking in drivers themselves still may make sense.
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Keyboard
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 a USB keyboard > > >> when booted from a "stock" Linux kernel. They only work with a RedHat > > >> kernel! I have removed all but one CPU from one in an attempt to find > > >> the problem. > > > [...] > > >> linux-2.6.8 linux-2.6.9 linux-2.6.10 linux-2.6.11 > > >> linux-2.6.11.9 linux-2.6.12 linux-2.6.12.5 linux-2.6.13 > > >> linux-2.6.13.4 linux-2.6.15.4 linux-2.6.16.24 linux-2.6.16.4 > > >> linux-2.6.19 > > > Could you please turn on USB debugging (and also maybe HID debugging, but > > > usb debug should be more interesting now) and send us the logs? > > Ouch! I can't do anything by copy from a screen! There is no way to get > > `dmesg` without the keyboard! That's why I sent a request to > > linux-kernel, hoping that the problem would sound familiar. All I can do > > is boot the system (off a CD-ROM) and then pull the plug when the > > keyboad doesn't work! > > You state that this happens on different hardware configurations, which > looks pretty strange, there are many 64bit amd systems with working USB > keyboards. > > Do you happen to have USB Legacy setting in BIOS? If so, could you try > turning it off? > > Also, does this happen only with one particular type of keyboard, or with > various ones? > Seeing .config might also be interesting. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Keyboard
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" > insmod /lib/usbhid.ko > echo "Loading usbkbd.ko module" > insmod /lib/usbkbd.ko > echo "sleeping for a few seconds" > sleep 2 > echo "Mounting root filesystem" > /bin/findroot > mount -o defaults --ro -t iso9660 /dev/root /sysroot > pivot_root /sysroot /sysroot/initrd > umount /initrd/proc > exec /sbin/init > -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iforce: Use usb_kill_urb instead of usb_unlink_urb.
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_kill_urb it loosk like the patch was just missed... > > On 3/17/07, johann deneux <[EMAIL PROTECTED]> wrote: > > > > commit 0ba8785483c2ee7f56e8f242e000f6cd17a7da40 > > Author: Johann Deneux <[EMAIL PROTECTED]> > > Date: Sat Mar 17 22:23:44 2007 +0100 > > > > iforce: Use usb_kill_urb instead of usb_unlink_urb. > > > > Using usb_unlink_urb can cause iforce_open to fail when called soon > > after iforce_release. > > Also updated my email address and replaced calls to printk() by dbg(), > > warn(), info(), err()... > > Since there seems a lot of implementations of r warn(), err(), etc what kind of output would iforce produce? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC/PATCH 0/7] Move USB input devices to drivers/input
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 keyboards, mice, joysticks in the same place instead of hunting for them across entire tree, depending on how they are connected to the box. Pleas elet me know if this is acceptable and if it is who is going to send this to Linus. Thanks! -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC/PATCH 3/7] move USB touchscreens under drivers/input/touchscreen
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/touchscreen/Kconfig | 60 +-
drivers/input/touchscreen/Makefile | 17
drivers/input/touchscreen/usbtouchscreen.c | 838 +
drivers/usb/input/Kconfig | 54 -
drivers/usb/input/Makefile |1
6 files changed, 904 insertions(+), 904 deletions(-)
Index: work/drivers/input/touchscreen/Kconfig
===
--- work.orig/drivers/input/touchscreen/Kconfig
+++ work/drivers/input/touchscreen/Kconfig
@@ -1,5 +1,5 @@
#
-# Mouse driver configuration
+# Touchscreen driver configuration
#
menuconfig INPUT_TOUCHSCREEN
bool "Touchscreens"
@@ -44,9 +44,9 @@ config TOUCHSCREEN_BITSY
config TOUCHSCREEN_CORGI
tristate "SharpSL (Corgi and Spitz series) touchscreen driver"
depends on PXA_SHARPSL
- default y
+ default y
help
- Say Y here to enable the driver for the touchscreen on the
+ Say Y here to enable the driver for the touchscreen on the
Sharp SL-C7xx and SL-Cxx00 series of PDAs.
If unsure, say N.
@@ -164,4 +164,58 @@ config TOUCHSCREEN_UCB1400
To compile this driver as a module, choose M here: the
module will be called ucb1400_ts.
+config TOUCHSCREEN_USB_COMPOSITE
+ tristate "USB Touchscreen Driver"
+ select USB
+ help
+ USB Touchscreen driver for:
+ - eGalax Touchkit USB (also includes eTurboTouch CT-410/510/700)
+ - PanJit TouchSet USB
+ - 3M MicroTouch USB (EX II series)
+ - ITM
+ - some other eTurboTouch
+ - Gunze AHL61
+ - DMC TSC-10/25
+
+ Have a look at <http://linux.chapter7.ch/touchkit/> for
+ a usage description and the required user-space stuff.
+
+ To compile this driver as a module, choose M here: the
+ module will be called usbtouchscreen.
+
+config TOUCHSCREEN_USB_EGALAX
+ default y
+ bool "eGalax, eTurboTouch CT-410/510/700 device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_PANJIT
+ default y
+ bool "PanJit device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_3M
+ default y
+ bool "3M/Microtouch EX II series device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_ITM
+ default y
+ bool "ITM device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_ETURBO
+ default y
+ bool "eTurboTouch (non-eGalax compatible) device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_GUNZE
+ default y
+ bool "Gunze AHL61 device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
+config TOUCHSCREEN_USB_DMC_TSC10
+ default y
+ bool "DMC TSC-10/25 device support" if EMBEDDED
+ depends on TOUCHSCREEN_USB_COMPOSITE
+
endif
Index: work/drivers/input/touchscreen/Makefile
===
--- work.orig/drivers/input/touchscreen/Makefile
+++ work/drivers/input/touchscreen/Makefile
@@ -1,17 +1,18 @@
#
-# Makefile for the mouse drivers.
+# Makefile for the touchscreen drivers.
#
# Each configuration option enables a list of files.
obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
-obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
-obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
-obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
-obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
-obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
-obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o
-obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
+obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
+obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
+obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o
+obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE)+= usbtouchscreen.o
obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
Index: work/drivers/input/touchscreen/usbtouchscreen.c
[linux-usb-devel] [RFC/PATCH 1/7] Input: remove old USB touchscreen 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 ---
drivers/usb/input/mtouchusb.c | 332 -
drivers/usb/input/touchkitusb.c | 392
drivers/usb/input/Makefile |3
4 files changed, 998 deletions(-)
Index: work/drivers/usb/input/Makefile
===
--- work.orig/drivers/usb/input/Makefile
+++ work/drivers/usb/input/Makefile
@@ -38,9 +38,6 @@ obj-$(CONFIG_USB_KBD) += usbkbd.o
obj-$(CONFIG_USB_KBTAB)+= kbtab.o
obj-$(CONFIG_USB_KEYSPAN_REMOTE) += keyspan_remote.o
obj-$(CONFIG_USB_MOUSE)+= usbmouse.o
-obj-$(CONFIG_USB_MTOUCH) += mtouchusb.o
-obj-$(CONFIG_USB_ITMTOUCH) += itmtouch.o
-obj-$(CONFIG_USB_EGALAX) += touchkitusb.o
obj-$(CONFIG_USB_TOUCHSCREEN) += usbtouchscreen.o
obj-$(CONFIG_USB_POWERMATE)+= powermate.o
obj-$(CONFIG_USB_WACOM)+= wacom.o
Index: work/drivers/usb/input/itmtouch.c
===
--- work.orig/drivers/usb/input/itmtouch.c
+++ /dev/null
@@ -1,271 +0,0 @@
-/**
- * itmtouch.c -- Driver for ITM touchscreen panel
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- * Based upon original work by Chris Collins <[EMAIL PROTECTED]>.
- *
- * Kudos to ITM for providing me with the datasheet for the panel,
- * even though it was a day later than I had finished writing this
- * driver.
- *
- * It has meant that I've been able to correct my interpretation of the
- * protocol packets however.
- *
- * CC -- 2003/9/29
- *
- * History
- * 1.0 & 1.1 2003 (CC) [EMAIL PROTECTED]
- * Original version for 2.4.x kernels
- *
- * 1.2 02/03/2005 (HCE) [EMAIL PROTECTED]
- * Complete rewrite to support Linux 2.6.10, thanks to mtouchusb.c for hints.
- * Unfortunately no calibration support at this time.
- *
- * 1.2.1 09/03/2005 (HCE) [EMAIL PROTECTED]
- * Code cleanup and adjusting syntax to start matching kernel standards
- *
- * 1.2.2 10/05/2006 (MJA) [EMAIL PROTECTED]
- * Flag for detecting if the screen was being touch was incorrectly
- * inverted, so no touch events were being detected.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-
-/* only an 8 byte buffer necessary for a single packet */
-#define ITM_BUFSIZE8
-#define PATH_SIZE 64
-
-#define USB_VENDOR_ID_ITMINC 0x0403
-#define USB_PRODUCT_ID_TOUCHPANEL 0xf9e9
-
-#define DRIVER_AUTHOR "Hans-Christian Egtvedt <[EMAIL PROTECTED]>"
-#define DRIVER_VERSION "v1.2.2"
-#define DRIVER_DESC "USB ITM Inc Touch Panel Driver"
-#define DRIVER_LICENSE "GPL"
-
-MODULE_AUTHOR( DRIVER_AUTHOR );
-MODULE_DESCRIPTION( DRIVER_DESC );
-MODULE_LICENSE( DRIVER_LICENSE );
-
-struct itmtouch_dev {
- struct usb_device *usbdev; /* usb device */
- struct input_dev*inputdev; /* input device */
- struct urb *readurb; /* urb */
- charrbuf[ITM_BUFSIZE]; /* data */
- int users;
- char name[128];
- char phys[64];
-};
-
-static struct usb_device_id itmtouch_ids [] = {
- { USB_DEVICE(USB_VENDOR_ID_ITMINC, USB_PRODUCT_ID_TOUCHPANEL) },
- { }
-};
-
-static void itmtouch_irq(struct urb *urb)
-{
- struct itmtouch_dev *itmtouch = urb->context;
- unsigned char *data = urb->transfer_buffer;
- struct input_dev *dev = itmtouch->inputdev;
- int retval;
-
- switch (urb->status) {
- case 0:
- /* success */
- break;
- case -ETIME:
- /* this urb is timing out */
- dbg("%s - urb timed out - was the device unplugged?",
- __FUNCTION__);
- return;
- case -
[linux-usb-devel] [RFC/PATCH 5/7] move USB gamepads under drivers/input/joystick
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/joystick/Kconfig | 18 +
drivers/input/joystick/Makefile |1
drivers/input/joystick/xpad.c | 428
drivers/usb/input/Kconfig | 14 -
drivers/usb/input/Makefile |1
6 files changed, 445 insertions(+), 445 deletions(-)
Index: work/drivers/input/joystick/Kconfig
===
--- work.orig/drivers/input/joystick/Kconfig
+++ work/drivers/input/joystick/Kconfig
@@ -2,7 +2,7 @@
# Joystick driver configuration
#
menuconfig INPUT_JOYSTICK
- bool "Joysticks"
+ bool "Joysticks/Gamepads"
help
If you have a joystick, 6dof controller, gamepad, steering wheel,
weapon control system or something like that you can say Y here
@@ -196,7 +196,7 @@ config JOYSTICK_TWIDJOY
config JOYSTICK_DB9
tristate "Multisystem, Sega Genesis, Saturn joysticks and gamepads"
depends on PARPORT
- ---help---
+ help
Say Y here if you have a Sega Master System gamepad, Sega Genesis
gamepad, Sega Saturn gamepad, or a Multisystem -- Atari, Amiga,
Commodore, Amstrad CPC joystick connected to your parallel port.
@@ -253,4 +253,18 @@ config JOYSTICK_JOYDUMP
To compile this driver as a module, choose M here: the
module will be called joydump.
+config JOYSTICK_XPAD
+ tristate "X-Box gamepad support"
+ select USB
+ help
+ Say Y here if you want to use the X-Box pad with your computer.
+ Make sure to say Y to "Joystick support" (CONFIG_INPUT_JOYDEV)
+ and/or "Event interface support" (CONFIG_INPUT_EVDEV) as well.
+
+ For information about how to connect the X-Box pad to USB, see
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called xpad.
+
endif
Index: work/drivers/input/joystick/Makefile
===
--- work.orig/drivers/input/joystick/Makefile
+++ work/drivers/input/joystick/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_JOYSTICK_TMDC) += tmdc.o
obj-$(CONFIG_JOYSTICK_TURBOGRAFX) += turbografx.o
obj-$(CONFIG_JOYSTICK_TWIDJOY) += twidjoy.o
obj-$(CONFIG_JOYSTICK_WARRIOR) += warrior.o
+obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
obj-$(CONFIG_JOYSTICK_IFORCE) += iforce/
Index: work/drivers/input/joystick/xpad.c
===
--- /dev/null
+++ work/drivers/input/joystick/xpad.c
@@ -0,0 +1,428 @@
+/*
+ * X-Box gamepad - v0.0.6
+ *
+ * Copyright (c) 2002 Marko Friedemann <[EMAIL PROTECTED]>
+ * 2004 Oliver Schwartz <[EMAIL PROTECTED]>,
+ *Steven Toth <[EMAIL PROTECTED]>,
+ *Franz Lehner <[EMAIL PROTECTED]>,
+ *Ivan Hawkes <[EMAIL PROTECTED]>
+ * 2005 Dominic Cerquetti <[EMAIL PROTECTED]>
+ * 2006 Adam Buchbinder <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ *
+ * This driver is based on:
+ * - information from http://euc.jp/periphs/xbox-controller.ja.html
+ * - the iForce driverdrivers/char/joystick/iforce.c
+ * - the skeleton-driver drivers/usb/usb-skeleton.c
+ *
+ * Thanks to:
+ * - ITO Takayuki for providing essential xpad information on his website
+ * - Vojtech Pavlik - iforce driver / input subsystem
+ * - Greg Kroah-Hartman - usb-skeleton driver
+ * - XBOX Linux project - extra USB id's
+ *
+ * TODO:
+ * - fine tune axes (especially trigger axes)
+ * - fix "analog" buttons (reported as digital now)
+ * - get rumble working
+ * - need USB IDs for other dance pads
+ *
+ * History:
+ *
+ * 2002-06-27 - 0.0.1 : first version, just said "XBOX HID controller"
+ *
+ * 2002-07-02 - 0.0.2 : basic working version
+ * - all ax
[linux-usb-devel] [RFC/PATCH 6/7] move USB keyboards under drivers/input/keyboard
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/keyboard/Kconfig | 21 ++
drivers/input/keyboard/Makefile |1
drivers/input/keyboard/usbkbd.c | 362
drivers/usb/input/Kconfig | 16 -
drivers/usb/input/Makefile |1
6 files changed, 383 insertions(+), 380 deletions(-)
Index: work/drivers/input/keyboard/Kconfig
===
--- work.orig/drivers/input/keyboard/Kconfig
+++ work/drivers/input/keyboard/Kconfig
@@ -1,5 +1,5 @@
#
-# Input core configuration
+# Keyboard driver configuration
#
menuconfig INPUT_KEYBOARD
bool "Keyboards" if EMBEDDED || !X86
@@ -238,4 +238,23 @@ config KEYBOARD_GPIO
To compile this driver as a module, choose M here: the
module will be called gpio-keys.
+comment "It is recommended to enable Full HID support instead of HIDBP drivers"
+ depends on USB_HID=n
+
+config KEYBOARD_USB_HIDBP
+ tristate "USB HIDBP Keyboard (simple Boot - use HID instead)"
+ depends on USB && USB_HID!=y
+ help
+ Say Y here only if you are absolutely sure that you don't want
+ to use the generic HID driver for your USB keyboard and prefer
+ to use the keyboard in its limited Boot Protocol mode instead.
+
+ This is almost certainly not what you want. This is mostly
+ useful for embedded applications or simple keyboards.
+
+ To compile this driver as a module, choose M here: the
+ module will be called usbkbd.
+
+ If even remotely unsure, say N.
+
endif
Index: work/drivers/input/keyboard/Makefile
===
--- work.orig/drivers/input/keyboard/Makefile
+++ work/drivers/input/keyboard/Makefile
@@ -20,4 +20,5 @@ obj-$(CONFIG_KEYBOARD_OMAP) += omap-key
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keyboard.o
obj-$(CONFIG_KEYBOARD_AAED2000)+= aaed2000_kbd.o
obj-$(CONFIG_KEYBOARD_GPIO)+= gpio_keys.o
+obj-$(CONFIG_KEYBOARD_USB_HIDBP) += usbkbd.o
Index: work/drivers/input/keyboard/usbkbd.c
===
--- /dev/null
+++ work/drivers/input/keyboard/usbkbd.c
@@ -0,0 +1,362 @@
+/*
+ * $Id: usbkbd.c,v 1.27 2001/12/27 10:37:41 vojtech Exp $
+ *
+ * Copyright (c) 1999-2001 Vojtech Pavlik
+ *
+ * USB HIDBP Keyboard support
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Should you need to contact me, the author, you can do so either by
+ * e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
+ * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Version Information
+ */
+#define DRIVER_VERSION ""
+#define DRIVER_AUTHOR "Vojtech Pavlik <[EMAIL PROTECTED]>"
+#define DRIVER_DESC "USB HID Boot Protocol keyboard driver"
+#define DRIVER_LICENSE "GPL"
+
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE(DRIVER_LICENSE);
+
+static unsigned char usb_kbd_keycode[256] = {
+ 0, 0, 0, 0, 30, 48, 46, 32, 18, 33, 34, 35, 23, 36, 37, 38,
+50, 49, 24, 25, 16, 19, 31, 20, 22, 47, 17, 45, 21, 44, 2, 3,
+ 4, 5, 6, 7, 8, 9, 10, 11, 28, 1, 14, 15, 57, 12, 13, 26,
+27, 43, 43, 39, 40, 41, 51, 52, 53, 58, 59, 60, 61, 62, 63, 64,
+65, 66, 67, 68, 87, 88, 99, 70,119,110,102,104,111,107,109,106,
+ 105,108,103, 69, 98, 55, 74, 78, 96, 79, 80, 81, 75, 76, 77, 71,
+72, 73, 82, 83, 86,127,116,117,183,184,185,186,187,188,189,190,
+ 191,192,193,194,134,138,130,132,128,129,131,137,133,135,136,113,
+ 115,114, 0, 0, 0,121, 0, 89, 93,124, 92, 94, 95, 0, 0, 0,
+ 122,123, 90, 91, 85, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0
Re: [linux-usb-devel] [RFC/PATCH 0/7] Move USB input devices to drivers/input
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 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 keyboards, mice, joysticks in the same place instead > > of hunting for them across entire tree, depending on how they are > > connected to the box. > > > > Pleas elet me know if this is acceptable and if it is who is going > > to send this to Linus. > > 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 <[EMAIL PROTECTED]> > added to all of these. > Ok, I'll add them to my tree then and wait for .22 merge window. Do you have any pending patches against USB input drivers? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC/PATCH 0/7] Move USB input devices to drivers/input
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 <[EMAIL PROTECTED]> > > > added to all of these. > > > Thanks for doing this. > > > > To complement this, I have the following patch queued in my tree (already > > in -mm for some time), which moves all hid-related USB code from > > drivers/usb/input to drivers/hid/usbhid, as discussed before. Does the > > some thing apply please? > > Yes it does, feel free to add my signed-off-by to it also. > > > The only clash we have here is the usbkbd.c and usbmouse.c - my patches > > move them into hid-specific directory, as they implement the 'boot' > > version of the HID standard. What do you think? > > That's fine, they need to stick around somewhere, and they are mini > "hid" drivers, but I'll let you and Dmitry fight over who gets to > maintain them, I have no preference :) > 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 using them and select full HID driver right there. Jiri, how will we handle merge? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC/PATCH 0/7] Move USB input devices to drivers/input
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, > > > > > > > > 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 keyboards, mice, joysticks in the same place instead > > > > of hunting for them across entire tree, depending on how they are > > > > connected to the box. > > > > > > > > Pleas elet me know if this is acceptable and if it is who is going > > > > to send this to Linus. > > > > > > 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 <[EMAIL PROTECTED]> > > > added to all of these. > > > > > > > Ok, I'll add them to my tree then and wait for .22 merge window. Do you > > have any pending patches against USB input drivers? > > I have one ati_remote2.c patch and something that touches the gtco > driver. I'll be glad to just forward them to you to handle if you want, > or I can handle you moving and the merge that way and then send them on > to you. Which ever is easier for you, I have no preference either way. > Just send them to me please. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC/PATCH 0/7] Move USB input devices to drivers/input
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 using them and select full HID driver right there. > > I would in fact be interested in how many people are actually using these > drivers. More than actually need it I bet. > Maybe this code movement is a good chance to give them better > names than usbkdb and usbmouse, so that they don't directly provoke 'hey, > I have usb keyboard and mouse, so I need to use these' thoughts in user's > heads? > > > Jiri, how will we handle merge? > > Either I can wait for you to push input changes, and after Linus merges > them I will rebase my changes on top of yours and push them, or I can push > my changes through you as soon as the merge window opens, and you push > them to Linus - whatever you think is better. > > Also the second one to do the merge should probably take care of removing > the drivers/usb/input directory, which is going to become empty, right? > Do you have any patches for the files that are currently in drivers/usb/input? If not maybe I should put your patch in my tree and merge it all together. This way Andrew will be able to pull from both our trees without conflicts. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 passed for processing to the driver. > I don't think it is a good idea to register driver for specific usages/reports. Quite often you want to adjust processing of a report for a specific device. What if there are 2 devices that need such quirks? How will you do hotplug and module loading? Emit new uevent for every report? Also, what about users and Kconfig? "Driver for usage 0x12345. Say Y if your hardware does not wotk correctly with defautl handler for this usage and require special processing"??? Just register based on VID/PID and provide standard hid_default_input_event() to drivers so they would call it for reports they don't need to do special processing on. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 standard way by the generic hid bus
> >> layer, and those reports that the driver registered to will be
> >> ignored by
> >> the layer, and passed for processing to the driver.
> >>
> >
> > I don't think it is a good idea to register driver for specific
> > usages/reports. Quite often you want to adjust processing of a report
> > for a specific device. What if there are 2 devices that need such
> > quirks? How will you do hotplug and module loading? Emit new uevent
> > for every report? Also, what about users and Kconfig? "Driver for
> > usage 0x12345. Say Y if your hardware does not wotk correctly with
> > defautl handler for this usage and require special processing"???
> >
> > Just register based on VID/PID and provide standard
> > hid_default_input_event() to drivers so they would call it for reports
> > they don't need to do special processing on.
> >
>
> I think the shadow driver can not share inputdev with the related
> fundamental driver, so here are two input devices for one hid_device,
> how we should process both? It seem we have three choices:
>
> 1. Shadow | Fundamental means
>
> I think this is Jiri said. Fundamental driver handle all common
> input events, and Shadow driver handle anther specific input events,
> this imply user space process need monitor both input devices at same
> time, I do not think this is good idea.
>
> 2. Shadow & Fundamental means
>
> Let Fundamental driver and Shadow driver work at same time! but
> shadow also handle specific input event. So, the user may get twice
> input events! For example, the keyboard input in console.
> Also, I do not like this.
>
> 3. Shadow ^ Fundamental means
>
> Let Shadow driver handle every thing, and fundamental device silent,
> even unregister it. I think this is best choice between them, this means
> have a bit of complex.
>
There should be one device and your driver should simply do:
static void my_driver_hid_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
if (special_processing_needed(usage)) {
do_special_processing(...);
input_event(field->hidinput->input, XXX, YYY, ZZZ);
...
} else
hidinput_hid_event(hid, field, usage, value);
}
That is pretty much it. Your driver is not a shadow driver, it is
regular driver on HID bus that just happens to use generic hander
for standard events.
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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_device from > its working driver, let this hid_device attach with our new specific > driver. then new driver will handle all input event later, so the your > words is same with the third choice in fact, is it right? if so, the > actual behavior is same with former HID simple interface. > I was thinking that as we write customized drivers we would add them (manually or automatically) to the HID blacklist so that generic driver would not bind to such devices. Then, as your driver loads it would parse reports and construct input device structure in the same fashion that it processes the reports - if it is an "interesting" report/usage it will handle setup itself; otherwise just call generic setup function shared with the generic HID driver. This way there is only one input device and there is no storm of add/remove events as we loking for the proper driver to bind to the device. Does this make sense? This would not quite work for (potentially out of tree) HID drivers brought in after compiling generic HID driver but that should be a very rate occurance and we still can manually bind such drivers via sysfs bind/unbind and new_id manipulations. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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
> +++ b/drivers/usb/input/hid-core.c
> @@ -458,6 +458,18 @@ static int usb_hidinput_input_event(struct input_dev
> *dev, unsigned int type, un
>return 0;
> }
>
> +static void usbhid_set_leds(struct hid_device *hid, unsigned int code, int
> val)
> +{
> + struct hid_field *field;
> + int offset;
> +
> + /* This is often called for the mouse half. */
> + if ((offset = hidinput_find_field(hid, EV_LED, code, &field)) != -1) {
> + hid_set_field(field, offset, val);
> + usbhid_submit_report(hid, field->report, USB_DIR_OUT);
> + }
> +}
> +
This is fine and that's what we do in atkbd probe but maybe we should
move that in input core and reset leds as part of
input_register_device()?
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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 driver to reset NumLock on probe. Like > > > this: > > > > > > --- a/drivers/usb/input/hid-core.c > > > This is fine and that's what we do in atkbd probe but maybe we should > > move that in input core and reset leds as part of > > input_register_device()? > > Sure, as long as it works. I think (as much as I understand), that we > already attempt to do this indirectly. input_register_device invokes > ->start handlers, and the kbd_start attempts to reset LEDs, but fails > because of the state filtering. > Not exactly... Keyboard handler's start method tries to bring state of new keyboard in sync with the state of the rest of keyboards. The purpose of start() is not to complete hardware initialization but to adjust logical state of the device according to handler's requirements... But I am backpedaling on my statement about moving it into input core. The driver (HID in this case) should properly reset the device before registering it with input layer. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 report using information retrieved from the report descriptor of
> the device. But this is in some way in contrary to one of the features
> this effort should be heading to, isn't it? We want to provide means how
> to bypass possible errors in HID descriptor of the device (or do any other
> possible quirky handling) - we want to be able to allow for completely
> different interpretation of fields than the generic HID parser would do,
> right?
>
> So I guess the above should rather be
>
> static void my_driver_hid_report(struct hid_device *hid, u8 *data,
>int size)
> {
> if (special_processing_needed(data)) {
> do_special_processing(...);
> input_event(field->hidinput->input, XXX, YYY, ZZZ);
> ...
> } else
> hid_input_report(hid, data, size);
> }
>
Well, this of course is most flexible, however I think that for most
drivers hooking into parsed data would be much easier. That means that
we need to allow defining 2 hooks - one for raw data and another for
parsed reports and let drivers decice which one they want to use.
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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 NumLock off, this confuses users. Quick double dab > > at NumLock fixes it, but it's not nice. > > What I am seeing on my Thinkpad is that when I boot _without_ an USB > keyboard NumLock is enabled. Switching to virtual console and back to > X fixes it which is why I have never bothered to debug it further. > Perhaps this is related? Should I give your patch a spin to see if it > fixes the problem? > Are you saying that NumLock LED is lit or that keyboard is in NumLock state? Does the same happen if you boot with init=/bin/bash? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 with our mind: The USB/base > driver works for it. However, the world is not faultless. This joystick > is buggy, its some keys need specific handling, our good friend udev > discover that there is also have another driver can handle it, so it > insert that kernel module, then our sweet leading role specific/shadow > HID driver appear on scene. Registering shadow driver let HID core clone > a hid_device first, and start new usage configuration processing for new > cloned hid_device (if we like, even I think we can reread reports from > physical device), the shadow driver can join with HID core to > custom/hook in this recofiguration processing. If this shadow driver is > input-able, the HID core will unregister working input device come from > USB/base hid_device, and register new input device for this shadow > hid_device. So we have not two input_dev for one HID device at same time. > No, please don't do that. As soon as there is a special driver written for a device that device's VID/PID should be added to generic HID blacklist. This way udev will load the proper driver right away and there will not be any flip-flopping of input devices. > When user A remove this shadow driver, the USB/base driver should resume > work for this joystick, IOW, it should register back its input device again. > Why would we want to revert to using generic HID's implementation if we know that it is broken for that particular device??? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 drivers are exceptions from the generic handling, so creating an > exceptional rule (entry in hid_blacklist) for them is not that bad. OK, > it's not the nicest thing on earth probably, but serves the purpose in > current vendors-trying-to-break-hardware-in-the-most-original-way world > quite well. > Potentially we could even generate 2nd blacklist table automatically by scanning MODULE_DEVICE_TABLEs for all drivers in HID directory and merge it with the table we currently maintain in hid-input.c > This is going to cause some headache to out-of-tree drivers. Oh well, do > we care that much? They still can be made to work using bind/unbind via sysfs, but at this moment there are 0 drivers for HID bus and hopefully people will be submittin them for inclusion. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 dynamically adjust HID ignore blacklist. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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 declaration here?
> >[...]
> > I'd say this is a little bit overcommented.
> >[...]
> > So as soon as you have the VIDs and PIDs of the hardware which
> > requires this, could you please update the patch and send it to me again?
>
> How about this?
Actually I think I will be adding the patch below, but it has to wait
till 2.6.22 as it requires input core to struct device conversion
patch.
What do you think?
--
Dmitry
Input: add generic suspend and resume for uinput devices
Automatically turn off leds and sound effects 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 ++
1 files changed, 80 insertions(+)
Index: work/drivers/input/input.c
===
--- work.orig/drivers/input/input.c
+++ work/drivers/input/input.c
@@ -997,10 +997,88 @@ static int input_dev_uevent(struct devic
return 0;
}
+static void input_dev_toggle(struct input_dev *dev,
+unsigned int type, unsigned int code,
+unsigned long *cap_bits, unsigned long *bits,
+int force_off)
+{
+ if (test_bit(code, cap_bits)) {
+ if (!force_off)
+ dev->event(dev, type, code, test_bit(code, bits));
+ else if (test_bit(code, bits))
+ dev->event(dev, type, code, 0);
+ }
+}
+
+static void input_dev_reset(struct input_dev *dev, int force_off)
+{
+ int i;
+
+ if (!dev->event)
+ return;
+
+ /* synchronize led state */
+ if (test_bit(EV_LED, dev->evbit))
+ for (i = 0; i <= LED_MAX; i++)
+ input_dev_toggle(dev, EV_LED, i,
+dev->ledbit, dev->led, force_off);
+
+ /* restore sound */
+ if (test_bit(EV_SND, dev->evbit))
+ for (i = 0; i <= SND_MAX; i++)
+ input_dev_toggle(dev, EV_SND, i,
+dev->sndbit, dev->snd, force_off);
+
+ if (!force_off && test_bit(EV_REP, dev->evbit)) {
+ dev->event(dev, EV_REP, REP_PERIOD, dev->rep[REP_PERIOD]);
+ dev->event(dev, EV_REP, REP_DELAY, dev->rep[REP_DELAY]);
+ }
+}
+
+#ifdef CONFIG_PM
+static int input_dev_suspend(struct device *dev, pm_message_t state)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+
+ mutex_lock(&input_dev->mutex);
+
+ if (dev->power.power_state.event != state.event) {
+ if (state.event == PM_EVENT_SUSPEND)
+ input_dev_reset(input_dev, 1);
+
+ dev->power.power_state = state;
+ }
+
+ mutex_unlock(&input_dev->mutex);
+
+ return 0;
+}
+
+static int input_dev_resume(struct device *dev)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+
+ mutex_lock(&input_dev->mutex);
+
+ if (dev->power.power_state.event != PM_EVENT_ON)
+ input_dev_reset(to_input_dev(dev), 0);
+
+ dev->power.power_state = PMSG_ON;
+
+ mutex_unlock(&input_dev->mutex);
+
+ return 0;
+}
+#endif /* CONFIG_PM */
+
static struct device_type input_dev_type = {
.groups = input_dev_attr_groups,
.release= input_dev_release,
.uevent = input_dev_uevent,
+#ifdef CONFIG_PM
+ .suspend= input_dev_suspend,
+ .resume = input_dev_resume,
+#endif
};
struct class input_class = {
@@ -1080,6 +1158,8 @@ int input_register_device(struct input_d
dev->rep[REP_PERIOD] = 33;
}
+ input_dev_reset(dev, 0);
+
if (!dev->getkeycode)
dev->getkeycode = input_default_getkeycode;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.20 1/1] usb/input updatedaiptek tablet driver
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), > > 1); > > I think that your mailer line-wrapped it after all. Most of it is ok, but > look at the line above, please. That seems broken. > No, I think it is just formatting of the source, not line wrapping. > I think Greg takes MIME, so maybe just attach it as a text/plain file? > Actually Greg ACKed moving input-related SUB drivers to driver/input so they all live together in same config menu, so I will be taking it. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Aiptektablet-users] [PATCH 2.6.20 1/1] usb/input updatedaiptek tablet driver
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) {
> return 0;
> + }
Does it make any sense to check for aiptek != NULL? sysfs attributes are now
orphaned upon removal request so unless a device is bound to aiptek driver
there is no way its show/store methods going to be called.
Plus we don't normally use open/close braces for single statements.
>
> /***
> * support routines for the 'pointer_mode' file. Note that this file
> @@ -1103,22 +1197,22 @@
>
> switch (aiptek->curSetting.pointerMode) {
> case AIPTEK_POINTER_ONLY_STYLUS_MODE:
> - s = "stylus";
> + s = pStylus;
> break;
>
> case AIPTEK_POINTER_ONLY_MOUSE_MODE:
> - s = "mouse";
> + s = pMouse;
> break;
>
> case AIPTEK_POINTER_EITHER_MODE:
> - s = "either";
> + s = pEither;
> break;
>
> default:
> - s = "unknown";
> + s = pUnknown;
> break;
> }
> - return snprintf(buf, PAGE_SIZE, "%s\n", s);
> + return snprintf(buf, PAGE_SIZE, pString, s);
> }
>
> static ssize_t
> @@ -1128,12 +1222,12 @@
> if (aiptek == NULL)
> return 0;
>
> - if (strcmp(buf, "stylus") == 0) {
> + if (strncmp(buf, pStylus, ARRAY_SIZE(pStylus)) == 0) {
> aiptek->newSetting.pointerMode =
> AIPTEK_POINTER_ONLY_STYLUS_MODE;
> - } else if (strcmp(buf, "mouse") == 0) {
> + } else if (strncmp(buf, pMouse, ARRAY_SIZE(pMouse)) == 0) {
> aiptek->newSetting.pointerMode = AIPTEK_POINTER_ONLY_MOUSE_MODE;
> - } else if (strcmp(buf, "either") == 0) {
> + } else if (strncmp(buf, pEither, ARRAY_SIZE(pEither)) == 0) {
> aiptek->newSetting.pointerMode = AIPTEK_POINTER_EITHER_MODE;
> }
I think if you had an array of string/constant pairs this code and above
would be much shorter and maintainable.
> return count;
> @@ -1157,18 +1251,18 @@
>
> switch (aiptek->curSetting.coordinateMode) {
> case AIPTEK_COORDINATE_ABSOLUTE_MODE:
> - s = "absolute";
> + s = pAbsolute;
> break;
>
> case AIPTEK_COORDINATE_RELATIVE_MODE:
> - s = "relative";
> + s = pRelative;
> break;
>
> default:
> - s = "unknown";
> + s = pUnknown;
> break;
> }
> - return snprintf(buf, PAGE_SIZE, "%s\n", s);
> + return snprintf(buf, PAGE_SIZE, pString, s);
> }
>
> static ssize_t
> @@ -1178,11 +1272,11 @@
> if (aiptek == NULL)
> return 0;
>
> - if (strcmp(buf, "absolute") == 0) {
> - aiptek->newSetting.pointerMode =
> + if (strncmp(buf, pAbsolute, ARRAY_SIZE(pAbsolute)) == 0) {
> + aiptek->newSetting.coordinateMode =
> AIPTEK_COORDINATE_ABSOLUTE_MODE;
> - } else if (strcmp(buf, "relative") == 0) {
> - aiptek->newSetting.pointerMode =
> + } else if (strncmp(buf, pRelative, ARRAY_SIZE(pRelative)) == 0) {
> + aiptek->newSetting.coordinateMode =
> AIPTEK_COORDINATE_RELATIVE_MODE;
> }
Same here.
> return count;
> @@ -1206,38 +1300,38 @@
>
> switch (TOOL_BUTTON(aiptek->curSetting.toolMode)) {
> case AIPTEK_TOOL_BUTTON_MOUSE_MODE:
> - s = "mouse";
> + s = pMouse;
> break;
>
> case AIPTEK_TOOL_BUTTON_ERASER_MODE:
> - s = "eraser";
> + s = pEraser;
> break;
>
> case AIPTEK_TOOL_BUTTON_PENCIL_MODE:
> - s = "pencil";
> + s = pPencil;
> break;
>
> case AIPTEK_TOOL_BUTTON_PEN_MODE:
> - s = "pen";
> + s = pPen;
> break;
>
> case AIPTEK_TOOL_BUTTON_BRUSH_MODE:
> - s = "brush";
> + s = pBrush;
> break;
>
> case AIPTEK_TOOL_BUTTON_AIRBRUSH_MODE:
> - s = "airbrush";
> + s = pAirbrush;
> break;
>
> case AIPTEK_TOOL_BUTTON_LENS_MODE:
> - s = "lens";
> + s = pLens;
> break;
>
> default:
> - s = "unknown";
> + s = pUnknown;
> break;
> }
> - return snprintf(buf, PAGE_SIZE, "%s\n", s);
> + return snprintf(buf, PAGE_SIZE, pString, s);
> }
>
> static ssize_t
> @@ -1247,19 +1341,19 @@
> if (aiptek == NULL)
> return 0;
>
> - if (strcmp(buf, "mouse") == 0) {
> + if (strncmp(buf, pMouse, ARRAY_SIZE(pMouse)) == 0) {
>
Re: [linux-usb-devel] linux-2.6.20.4-ck1 / evdev / hub crash
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, which I had been on > > for a couple of days before this, when X started I noticed that my MX > > Revolution mouse didn't work, so I tried to restart KDM (every now and > > again evdev fails, has problems). When that didn't work I decided to > > remove and reinstall the receiver from the hub, when I did I noticed X > > wouldn't start any more and my dmesg[2] had a dump. Also including a > > copy of my .config[3] (slightly modified for use with a newer kernel). > > This isn't a reoccurring issue, yet, just wanted to report it in case > > it's of any use, thanks. I'm not on the list, please CC me if anything > > is needed. > > 1. > > http://ck.kolivas.org/patches/pre-releases/2.6.20.4/2.6.20.4-ck1/patch-2.6.20.4-ck1.bz2 > > 2. http://avuton.googlepages.com/evdev_dump > > 3. http://avuton.googlepages.com/config > > Hi, > > I added Dmitry and linux-input mailinglist to CC. This is the second time > I see oops on dereferencing 0x00100100 pointer in evdev_disconnect() > called from input_unregister_device() > - the first one is DVB-T related thing reported a few days ago here - > http://lkml.org/lkml/2007/3/9/212 > Could you please try 2.6.21-rc5-mm4? It has evdev locking patch that I believe should fix these kind of oopses. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] linux-2.6.20.4-ck1 / evdev / hub crash
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 problem testing it, but since that oops, it hasn't > reoccurred I couldn't reproduce it when I attempted (about 20-30 > pull-outs). Obviously, if there's some reason for me to try, I will, > but I don't see any advantage to you or I. OK. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
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 :)
> >
> >
> There is a "presentable patch" in the attachment ;)
Some random notes without reading it all carefully...
> +static int hid_bus_match(struct device *dev, struct device_driver
> *drv) +{
> + struct hid_driver *hid_drv;
> + struct hid_device *hid_dev;
> +
> + hid_drv = to_hid_driver(drv);
> + hid_dev = to_hid_device(dev);
> +
> + if (is_hid_driver_sticky(hid_drv))
> + /* the sticky driver match device do not pass here. */
> + return 0;
> + if (hid_dev->bus != hid_drv->bus)
> + return 0;
How can this happen?
> + if (!hid_drv->match || hid_drv->match(hid_drv, hid_dev)) {
> + hid_dev->driver = hid_drv;
This usually done in bus->probe() function, when we know for sure that
driver binds to to the device.
> +static void hid_bus_release(struct device *dev)
> +{
> +}
> +
> +struct device hid_bus = {
> + .bus_id = "hidbus0",
> + .release = hid_bus_release
> +};
> +
> +static void hid_dev_release(struct device *dev)
> +{
> +}
> +
That will for sure raise Greg KH's blood pressure ;)
> + for (i=0; hid_dev->attrs && hid_dev->attrs[i]; ++i) {
> + ret = device_create_file(&hid_dev->device, hid_dev->attrs[i]);
> + if (ret)
> + break;
> +
That should be handled via bus's device attributes and not open coded...
> - * Copyright (c) 2000-2005 Vojtech Pavlik <[EMAIL PROTECTED]>
> - * Copyright (c) 2005 Michael Haboustak <[EMAIL PROTECTED]> for Concept2,
> Inc
> + * Copyright (c) 2000-2005 Vojtech Pavlik
> + * Copyright (c) 2005 Michael Haboustak for Concept2,
> Inc
> * Copyright (c) 2006 Jiri Kosina
Any particular reason for mangling addresses?
> + if (interrupt)
> + local_irq_save(flags);
> + spin_lock(&hid_lock);
> + list_for_each_entry(driver, &hid_sticky_drivers, sticky_link) {
> + hook = driver->hook;
> + if (hook && hook->raw_event) {
> + ret = hook->raw_event(hid, type, data, size, interrupt);
> + if (!ret)
> + break;
> + }
> + }
> + spin_unlock(&hid_lock);
> + if (interrupt)
> + local_irq_restore(flags);
> +
This is scary. spin_lock_irqsave() and be done with it.
> +int hid_open(struct hid_device *hid)
> +{
> + struct hid_transport *tl;
> + int ret;
> +
> + if (hid->driver->open)
> + return hid->driver->open(hid);
> + ret = 0;
> + spin_lock(&hid_lock);
> + tl = hid_transports[hid->bus];
> + if (tl->open)
> + ret = tl->open(hid);
> + spin_unlock(&hid_lock);
> + return ret;
> +}
Spinlock is not the best choise here, I'd expect most ->open()
implementation wait on some IO.
--
Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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 be > needed. Could you please let me know? 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 leds after all. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
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 crash if anything unusual > happens. > You know, I would not call turning leds on an off an unusual operation for a keyboard. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb touchscreen breakage in 2.6.21-rc5-mm4 ?
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 order to save boot time. > > The strange thing is, 2.6.21-rc5-mm4 recognizes the device. > dmesg says things like > usb 3-2: Manufacturer: eGalac Inc. > usb 3-2: Product: USB TouchController > > and a lot more. Unlike 2.6.18, it never gets around to say > "usbcore: registered new driver usbtouchscreen" > which seems to indicate a problem. > usbcore registers several other drivers, such as usbserial and pl2303 > that makes the gps work. It also registers other drivers like > usb-storage,usbfs,hub,libusual,hiddev,usbhid. But not usbtouchscreen. > I believe I have turned on every config option for usb touchscreen, > this should not be missing. > > Is there something wrong, or could there be a seemingly unrelated option > that I need to turn on? Please make sure that you have CONFIG_USB_TOUCHSCREEN turned on. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb touchscreen breakage in 2.6.21-rc5-mm4 ?
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.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 order to save boot time. > > > > > > The strange thing is, 2.6.21-rc5-mm4 recognizes the device. > > > dmesg says things like > > > usb 3-2: Manufacturer: eGalac Inc. > > > usb 3-2: Product: USB TouchController > > > > > > and a lot more. Unlike 2.6.18, it never gets around to say > > > "usbcore: registered new driver usbtouchscreen" > > > which seems to indicate a problem. > > > usbcore registers several other drivers, such as usbserial and pl2303 > > > that makes the gps work. It also registers other drivers like > > > usb-storage,usbfs,hub,libusual,hiddev,usbhid. But not usbtouchscreen. > > > I believe I have turned on every config option for usb touchscreen, > > > this should not be missing. > > > > > > Is there something wrong, or could there be a seemingly unrelated option > > > that I need to turn on? > > > > Please make sure that you have CONFIG_USB_TOUCHSCREEN turned on. > > > Unfortunately, I have: > CONFIG_USB_TOUCHSCREEN=y > CONFIG_USB_TOUCHSCREEN_EGALAX=y > > Anything else I may have missed? > 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 booting with debug_initcall to see with what error code usbtouchscreen initialization fails? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb touchscreen breakage in 2.6.21-rc5-mm4 ?
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 booting with debug_initcall to see with what error code usbtouchscreen > > initialization fails? > > > Here is the dmesg from a boot with debug_initcall. > I can't see any messages from usbtouchscreen. > For me, it looks like the touchscreen is discovered and then > nothing happens to it. > *sigh* When will I learn to spell names of kernel parameters correctly? It is initcall_debug, not debug_initcall :( Could you try again, please? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb touchscreen breakage in 2.6.21-rc5-mm4 ?
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 rc5mm4 with initcall_debug, showing how > no usbtouch function is called at all. > Helge, I don't have any explanation why we don't see usbtouch_init called at all in -rc5-mm4. Could it be toolchain misbehaving? Do you see references to usbtouch_init in the kernel image itself? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 1/3] xpad.c: Added flags into xpad_device structure and removed dpad_mapping.
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 device is a wheel? Or if the device can have keyboard (or headset) > attached. > ... > -#define MAP_DPAD_TO_BUTTONS0 > -#define MAP_DPAD_TO_AXES 1 > -#define MAP_DPAD_UNKNOWN -1 > +#define XPAD_FLAGS_DPAD_TO_BUTTONS(1 << 0) > +#define XPAD_FLAGS_DPAD_TO_AXES (1 << 1) > +#define XPAD_FLAGS_DPAD_UNKNOWN (1 << 2) > Turning this into bitmaps suggests that all of these could be set which is not the case. Since there are 3 spare bytes in xpad_device structure to use for additional flags/bitmaps I'd leave dpad_mapping alone. -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.
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)
> +{
> + int retval;
> +
> + switch (urb->status) {
> + case 0:
> + /* success */
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + /* this urb is terminated, clean up */
> + dbg("%s - urb shutting down with status: %d",
> __FUNCTION__, urb->status);
> + return;
> + default:
> + dbg("%s - nonzero urb status received: %d",
> __FUNCTION__, urb->status);
> + goto exit;
> + }
> +
> +exit:
> + retval = usb_submit_urb(urb, GFP_ATOMIC);
> + if (retval)
> + err("%s - usb_submit_urb failed with result %d",
> +__FUNCTION__, retval);
> +}
> +
> +int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect
> *effect)
> +{
> + struct usb_xpad *xpad = dev->private;
> + if (effect->type == FF_RUMBLE) {
> + __u16 strong = effect->u.rumble.strong_magnitude;
> + __u16 weak = effect->u.rumble.weak_magnitude;
> + xpad->odata[0] = 0x00;
> + xpad->odata[1] = 0x08;
> + xpad->odata[2] = 0x00;
> + xpad->odata[3] = strong / 256;
> + xpad->odata[4] = weak / 256;
> + xpad->odata[5] = 0x00;
> + xpad->odata[6] = 0x00;
> + xpad->odata[7] = 0x00;
> + usb_submit_urb(xpad->irq_out, GFP_KERNEL);
> + }
> +
> + return 0;
> +}
> +
> +static int xpad_init_ff(struct usb_interface *intf, struct usb_xpad *xpad)
> +{
> + if (xpad->flags & XPAD_FLAGS_XBOX360) {
> + struct usb_endpoint_descriptor *ep_irq_out;
> + int rv;
> +
> + xpad->odata = usb_buffer_alloc(xpad->udev, XPAD_PKT_LEN,
> +GFP_ATOMIC, &xpad->odata_dma );
> + if (!xpad->idata)
> + goto fail1;
> +
> + xpad->irq_out = usb_alloc_urb(0, GFP_KERNEL);
> + if (!xpad->irq_out)
> + goto fail2;
> +
> +
> + ep_irq_out = &intf->cur_altsetting->endpoint[1].desc;
> + usb_fill_int_urb(xpad->irq_out, xpad->udev,
> + usb_sndintpipe(xpad->udev,
> ep_irq_out->bEndpointAddress),
> + xpad->odata, XPAD_PKT_LEN,
> + xpad_irq_out, xpad, ep_irq_out->bInterval);
> + xpad->irq_out->transfer_dma = xpad->odata_dma;
> + xpad->irq_out->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
> +
> + set_bit( FF_RUMBLE, xpad->dev->ffbit );
> + rv = input_ff_create_memless(xpad->dev, NULL, xpad_play_effect);
> +
Error handling seems to be missing.
> + return 0;
> +
> +fail2: usb_buffer_free(xpad->udev, XPAD_PKT_LEN, xpad->odata,
> xpad->odata_dma);
> +fail1:
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +
> +static void xpad_deinit_ff(struct usb_interface *intf, struct usb_xpad *xpad)
> +{
> + if (xpad->flags & XPAD_FLAGS_XBOX360) {
> + usb_kill_urb(xpad->irq_out);
You may want to do that in xpad_close().
> + usb_free_urb(xpad->irq_out);
> + usb_buffer_free(interface_to_usbdev(intf), XPAD_PKT_LEN,
> + xpad->odata, xpad->odata_dma);
> + }
> +}
> +#endif
> +
> static int xpad_open (struct input_dev *dev)
> {
> struct usb_xpad *xpad = dev->private;
> @@ -432,6 +535,11 @@ static int xpad_probe(struct usb_interface *intf, const
> struct usb_device_id *id
>
> input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
>
> +#ifdef CONFIG_XPAD_FF
> + if (xpad->flags & XPAD_FLAGS_XBOX360)
> + input_dev->evbit[0] |= BIT(EV_FF);
> +#endif
Can this be moved into xpad_init_ff?
> +
> /* set up buttons */
> for (i = 0; xpad_btn[i] >= 0; i++)
> set_bit(xpad_btn[i], input_dev->keybit);
> @@ -449,6 +557,11 @@ static int xpad_probe(struct usb_interface *intf, const
> struct usb_device_id *id
> for (i = 0; xpad_abs_pad[i] >= 0; i++)
> xpad_set_up_abs(input_dev, xpad_abs_pad[i]);
>
> +#ifdef CONFIG_XPAD_FF
> + if (xpad_init_ff(intf, xpad))
> + goto fail2;
> +#endif
> +
Normally we define dummy fucntions when corresponding config option is disabled
to avoid littering main code with #ifdefs.
> ep_irq_in = &intf->cur_altsetting->endpoint[0].desc;
> usb_fill_int_urb(xpad->irq_in, udev,
>usb_rcvintpipe(udev, ep_irq_in->bEndpointAddress),
> @@ -476,6 +589,9 @@ s
Re: [linux-usb-devel] [PATCH] [RFC] Added USB_DEVICE_INTERFACE_PROTOCOL
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 > > > > Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]> > > I have no objection to this, other than you need an additional newline > after the #define :) > > Dmitry, I can take this through my tree, or you can take it through > yours, as I think the other patches in this series depend on this. > > If you want to take it through yours, feel free to add: > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > I will grab it once some issues with the patch set are resolved. Thanks, -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] Onetouch - switch to using input_dev->dev.parent
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]>
---
drivers/usb/storage/onetouch.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Index: work/drivers/usb/storage/onetouch.c
===
--- work.orig/drivers/usb/storage/onetouch.c
+++ work/drivers/usb/storage/onetouch.c
@@ -84,7 +84,7 @@ resubmit:
static int usb_onetouch_open(struct input_dev *dev)
{
- struct usb_onetouch *onetouch = dev->private;
+ struct usb_onetouch *onetouch = input_get_drvdata(dev);
onetouch->is_open = 1;
onetouch->irq->dev = onetouch->udev;
@@ -98,7 +98,7 @@ static int usb_onetouch_open(struct inpu
static void usb_onetouch_close(struct input_dev *dev)
{
- struct usb_onetouch *onetouch = dev->private;
+ struct usb_onetouch *onetouch = input_get_drvdata(dev);
usb_kill_urb(onetouch->irq);
onetouch->is_open = 0;
@@ -185,13 +185,14 @@ int onetouch_connect_input(struct us_dat
input_dev->name = onetouch->name;
input_dev->phys = onetouch->phys;
usb_to_input_id(udev, &input_dev->id);
- input_dev->cdev.dev = &udev->dev;
+ input_dev->dev.parent = &udev->dev;
set_bit(EV_KEY, input_dev->evbit);
set_bit(ONETOUCH_BUTTON, input_dev->keybit);
clear_bit(0, input_dev->keybit);
- input_dev->private = onetouch;
+ input_set_drvdata(input_dev, onetouch);
+
input_dev->open = usb_onetouch_open;
input_dev->close = usb_onetouch_close;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 00/18] aiptek tablet patch series
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 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.
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 changes, thank you. -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 3/3] xpad.c: Added Xbox360 gamepad rumble support.
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. This > patch adds support to control them. > > This device understand to 14 messages (described at > http://www.free60.org/wiki/Gamepad#LED_Control). > > Control is done through event interface, message type EV_LED. EV_LED isn't > perfect match because you are actualy not turning some led on or off but > more likely you are telling the gamepad what "flash effect" it should > play. > I would rather it used led subsystem for this. -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug creating USB endpoints in 2.6.20.x (kernel bug 8198)
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 the file is accessed or closed later but it should fix > >> the bug winecfg triggers. I really dunno how to fix this the right way > >> in the stable kernel. Better ideas? Anyone? > > > > How about a WARN() and a small(?) memory leak? Better than an oops, surely? > > Device node creation/deletion can be quite often depending on > configuration, so I don't think we can afford memory leak here. It can > develop into a big problem for long running hosts. IMHO, just > introducing module unload/deletion race is much better. It's the lesser > evil, difficult to trigger and already broken in other places anyway. > > I think we need to hear what other people are thinking about it. Cc'ing > Maneesh, Dmitry and Cornelia. The whole thread can be read at... > > http://thread.gmane.org/gmane.linux.usb.devel/53559 > http://thread.gmane.org/gmane.linux.usb.devel/53846 > > The thread is rather long but just reading the message from the second > URL should be enough. The problem is that dev->devt_attr (class dev has > the same problem) is deallocated when the device is deleted. If the dev > sysfs attribute has users at that point, the dev sysfs node is left with > garbled struct attribute causing oops later. > > IMHO, the proper fix for this is immediate-disconnect which is no in -mm > as the problem is caused by expecting immediate-disconnect behavior when > it isn't implemented. > > As written above, I think it's better to risk module unload / sysfs race > than keeping the current sysfs deletion / open race. What do you guys > think? > How about embedding struct attribute fro devt into struct [class_]device for now? It is not too big and device is still going to be pinned into memory while there are sysfs users... I don't like fattening of device structures but leaks and/or oopses are worse in my book. -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Cannot find our GTCO USB Driver in the 2.6.22-rc1 kernel
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 tablets menu. This way it's more obvious that it's disabled > > if it's the only entry in the menu. Plus the parent menu gets > > cleaned up as well. > > Because some people want to be able to turn off entire set of options without having to descend into submenu. -- Dmitry P.S. Please do not top-post. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
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 looks like you are now in the same position I was some time ago WRT to debug information for i8042 - constantly asking people to enable debug, recompile and send the results. May I recommend changing CONFIG_HID_DEBUG to "default y if !EMBEDDED" and controlling debug output via a module parameter? -ENOPATCH though... -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Oops in khubd
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 on the codepath and it > doesn't go oops. > I think this commit should help: http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=fe838febd49be7b8013ae433a6424693180333b5 I just asked Linus to pull it so 2.6.22 does not crash so often while I am fixing locking properly for 2.6.23. -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] appletouch powersaving - please apply for 2.6.23-rc1
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_urb(dev->urb);
>input_unregister_device(dev->input);
>usb_buffer_free(dev->udev, dev->datalen,
>
This should go into atp_close() and I think you need to do
cancel_work_sync after calling usb_kill_urb() otherwise you risk it
being submitted while you gettingto kill the urb.
How many boxes did you try this patch on?
--
Dmitry
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] appletouch powersaving - please apply for 2.6.23-rc1 take #3
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 +699,7 @@ static void atp_disconnect(struct usb_interface
> > > *iface)
> > >
> > >usb_set_intfdata(iface, NULL);
> > >if (dev) {
> > > + cancel_work_sync(&dev->work);
> > >usb_kill_urb(dev->urb);
> > >input_unregister_device(dev->input);
> > >usb_buffer_free(dev->udev, dev->datalen,
> > >
> >
> > This should go into atp_close() and I think you need to do
> > cancel_work_sync after calling usb_kill_urb() otherwise you risk it
> > being submitted while you gettingto kill the urb.
>
> good catch. modified patch accordingly+attached.
>
> > How many boxes did you try this patch on?
>
> Mine plus 1 other. However please note that Matthews patch has been
> (which is what this patch is based on) is in the mactel-patches
> repository for quite some time now and that the not-yet-cleanup up
> variant of this patch was posted to mactel-devel...
>
> So the modeswitch part should work...
>
OK, can I please get signed-off-bys for the latest version so I can
apply it?
Thanks!
--
Dmitry
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: add support for Maxtor One-Touch button
Hi, On Thursday 28 July 2005 16:49, Matthew Dharm wrote: > + onetouch->dev.id.bustype = BUS_USB; > + onetouch->dev.id.vendor = le16_to_cpu(udev->descriptor.idVendor); > + onetouch->dev.id.product = le16_to_cpu(udev->descriptor.idProduct); > + onetouch->dev.id.version = le16_to_cpu(udev->descriptor.bcdDevice); > + > usb_to_input_id() has been merged in mainline, if the patch was not applied yet can we please use it here? Thanks! -- Dmitry --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: add support for Maxtor One-Touch button
On 8/1/05, Nick Sillik <[EMAIL PROTECTED]> wrote: > Dmitry Torokhov wrote: > >>+ onetouch->dev.id.bustype = BUS_USB; > >>+ onetouch->dev.id.vendor = le16_to_cpu(udev->descriptor.idVendor); > >>+ onetouch->dev.id.product = le16_to_cpu(udev->descriptor.idProduct); > >>+ onetouch->dev.id.version = le16_to_cpu(udev->descriptor.bcdDevice); > > > > usb_to_input_id() has been merged in mainline, if the patch was not applied > > yet can we please use it here? > > Dmitry... > > There was a reason I didn't do it this way... But I don't remember now. > > Once it's merged, I'll try to remember. Sound good? > That's fine... Although I don't think that there is a problem with using usb_to_input_id() as it is exactly those 4 lines moved into a function. -- Dmitry --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook
On Monday 31 October 2005 22:09, David Brownell wrote:
> > > > I'm not sure it's legal to do pci_enable_device() from within a pci
> > > > quirk anyway. I really wonder what that code is doing in the quirks, I
> > > > don't think it's the right place, but I may be wrong.
> > >
> > > Erm, what "code is doing" what, that you mean ??
> >
> > What _That_ code is doing in the quirks... shouldn't it be in the
> > {U,O,E}HCI drivers instead ?
>
> Not for PCI. Vojtech, this is your cue to explain some of how late handoff
> borks the input layer, as observed by SuSE on way too many BIOS/hardware
> combos
> for me to remember ... :)
>
Not Vojtech, but here is goes... Not everyone has USB compiled in and
even then I think USB is registered after serio. So when we probe for
i8042 BIOS still has its dirty hands on USB controllers and pretends
that they are in fact PS/2 devices. Crazy stuff like that... That's
why we can't keep that code in HCI drivers.
--
Dmitry
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH]USB: fix 'unused variable' warning
USB: fix 'unused variable' warning
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/core/message.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
Index: work/drivers/usb/core/message.c
===
--- work.orig/drivers/usb/core/message.c
+++ work/drivers/usb/core/message.c
@@ -1457,12 +1457,11 @@ free_interfaces:
*/
for (i = 0; i < nintf; ++i) {
struct usb_interface *intf = cp->interface[i];
- struct usb_host_interface *alt = intf->cur_altsetting;
dev_dbg (&dev->dev,
"adding %s (config #%d, interface %d)\n",
intf->dev.bus_id, configuration,
- alt->desc.bInterfaceNumber);
+ intf->cur_altsetting->desc.bInterfaceNumber);
ret = device_add (&intf->dev);
if (ret != 0) {
dev_err(&dev->dev,
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH] Driver for ATI/Philips USB RF remotes
On Sunday 27 November 2005 12:23, Alan Stern wrote: > Today 12:23:33 > > On Sun, 27 Nov 2005, Ville Syrjälä wrote: > > > > I suspect you are triggering a bug in the input layer. Adding a few > > > debugging lines to the test driver, particularly in usbtest_delete, might > > > help pinpoint the bug. > > > > It explodes when I call input_free_device() which just a wrapper for > > kfree(). And now I see the reason for the double free. > > input_dev_release() also does kfree() on the input_dev. > > > > So the question is: Why does input_free_device() even exist? > > You should ask Dmitry Torokhov (CC'ed). > input_free_device() is supposed to be called after input_alloc_device() if ->probe() function fails before calling input_register_device() or if input_register_device() fails. The reason there is input_free_device() instead of just using kfree() is because down the road input_allocate_device() may start doing something more and simple kfree() will not be enough. -- Dmitry --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH] Driver for ATI/Philips USB RF remotes
On Sunday 27 November 2005 11:30, Ville Syrjälä wrote: > Actually input_device_register() can't actually fail so checking the > return value isn't really needed. > It can fail now and I have a patch that will cause it fail if it fails to register device/attributes, so please check the return value in the new code. -- Dmitry --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Driver for ATI/Philips USB RF remotes
Hi,
On Saturday 10 December 2005 13:30, Ville Syrjälä wrote:
> +
> + input_regs(idev, regs);
> + input_event(idev, EV_REL, REL_X, (s8) data[1]);
> + input_event(idev, EV_REL, REL_Y, (s8) data[2]);
> + input_sync(idev);
> +}
We have input_report_rel()
> +
> + input_regs(idev, regs);
> + input_event(idev, EV_KEY, ati_remote2_key_table[index].key_code,
> data[1]);
> + input_sync(idev);
> +}
And input_report_key()
> +
> +static int ati_remote2_input_init(struct ati_remote2 *ar2)
> +{
> + struct input_dev *idev;
> + int i;
> +
> + idev = input_allocate_device();
> + if (!idev)
> + return -ENOMEM;
> +
> + ar2->idev = idev;
> + idev->private = ar2;
> +
> + idev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP) | BIT(EV_REL);
> + idev->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_RIGHT);
> + idev->relbit[0] = BIT(REL_X) | BIT(REL_Y);
> + for (i = 0; ati_remote2_key_table[i].key_code != KEY_RESERVED; i++)
> + set_bit(ati_remote2_key_table[i].key_code, idev->keybit);
> +
> + idev->rep[REP_DELAY] = 250;
> + idev->rep[REP_PERIOD] = 33;
Do you disable autorepeat on purpose? Because if you set repeat delay and
period by yourself you also need to provide your own timer handler.
>
> obj-$(CONFIG_USB_AIPTEK) += aiptek.o
> obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.o
> +obj-$(CONFIG_USB_ATI_REMOTE2)+= ati_remote2.o
I wonder - can these 2 drivers be folded into one? They seem somewhat
similar...
--
Dmitry
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Driver for ATI/Philips USB RF remotes
On Sunday 11 December 2005 23:40, Ville Syrjälä wrote:
> On Sun, Dec 11, 2005 at 10:28:46PM -0500, Dmitry Torokhov wrote:
> > Hi,
> >
> > On Saturday 10 December 2005 13:30, Ville Syrjälä wrote:
> > > +
> > > + input_regs(idev, regs);
> > > + input_event(idev, EV_REL, REL_X, (s8) data[1]);
> > > + input_event(idev, EV_REL, REL_Y, (s8) data[2]);
> > > + input_sync(idev);
> > > +}
> >
> > We have input_report_rel()
>
> That could be used, but since I couldn't use input_report_key() I
> decided not to use this one either.
>
OK...
> > > +
> > > + input_regs(idev, regs);
> > > + input_event(idev, EV_KEY, ati_remote2_key_table[index].key_code,
> > > data[1]);
> > > + input_sync(idev);
> > > +}
> >
> > And input_report_key()
>
> It won't allow repeat events (data[1] == 2).
>
Right...
> > > +static int ati_remote2_input_init(struct ati_remote2 *ar2)
> > > +{
> > > + struct input_dev *idev;
> > > + int i;
> > > +
> > > + idev = input_allocate_device();
> > > + if (!idev)
> > > + return -ENOMEM;
> > > +
> > > + ar2->idev = idev;
> > > + idev->private = ar2;
> > > +
> > > + idev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP) | BIT(EV_REL);
> > > + idev->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_RIGHT);
> > > + idev->relbit[0] = BIT(REL_X) | BIT(REL_Y);
> > > + for (i = 0; ati_remote2_key_table[i].key_code != KEY_RESERVED; i++)
> > > + set_bit(ati_remote2_key_table[i].key_code, idev->keybit);
> > > +
> > > + idev->rep[REP_DELAY] = 250;
> > > + idev->rep[REP_PERIOD] = 33;
> >
> > Do you disable autorepeat on purpose? Because if you set repeat delay and
> > period by yourself you also need to provide your own timer handler.
>
> The hardware provides repeat events itself. I just ignore them if not
> enough time has elapsed.
>
But you can't control hardware repeat rate, can you? If you leave that
to input core user can control the delay and repeat rate.
> > > obj-$(CONFIG_USB_AIPTEK) += aiptek.o
> > > obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.o
> > > +obj-$(CONFIG_USB_ATI_REMOTE2)+= ati_remote2.o
> >
> > I wonder - can these 2 drivers be folded into one? They seem somewhat
> > similar...
>
> They are more different than similar IMO.
>
> ati_remote hardware has one interface with one in and one out endpoint.
> ati_remote2 hardware has two interfaces with one in endpoint each. That
> means the init/exit code would need two code paths.
>
> ati_remote2 hardware handles mouse pad accel and keyboard repeat but
> ati_remote (I think) handles them in software. So the event handling
> would need two code paths.
>
I am not convinced that we should rely on hardware repeat. As fas as
initializationm goes you could attach driver-specific data controlling
initialization to the device ID table. That would unclutter init/exit
routine while allowing sharing bunch of the code.
--
Dmitry
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usblp suspend failure with 2.6.15-rc5
On Wednesday 14 December 2005 01:10, Greg KH wrote: > Alan, I'm starting to get some complaints about this issue (almost no > usb drivers have a suspend/resume function, nor should they be required > to.) Greg, Will you object to adding suspend/resume support to individual USB drivers? Relying on disconnect/rediscovery at resume does not work well for input devices... Now if X could dynamically add input devices we would not care, but unfortunately we need to keep the same device node if possible. -- Dmitry --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usblp suspend failure with 2.6.15-rc5
On 12/14/05, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 13 December 2005 11:10 pm, Dmitry Torokhov wrote: > > > Will you object to adding suspend/resume support to individual USB drivers? > > Relying on disconnect/rediscovery at resume does not work well for input > > devices... Now if X could dynamically add input devices we would not care, > > but unfortunately we need to keep the same device node if possible. > > I think the HID driver has had suspend/resume support for over a year > now, so that particular issue is resolved. :) > There are many more input drivers in the tree (aiptek, wacom, ati remote, etc, etc) so this issue is far from resolved. -- Dmitry --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [RFC] Changes to the driver model class code.
Hi Greg, On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > So I'll be slowly converting the kernel over to using this new > interface, and when finished, I can get rid of the old class apis (or > actually, just make them static) so that no one can implement them > improperly again... I disagree with this last step. What I liked about the driver model is that once you convert (properly) subsystem to using it you automatically get your proper refcounting and memory gets released at proper time. The change as it proposed disconnects class device instance from the meat so separate refcounting implementation isneeded. This increases maintenance costs. I always viewed class_simple as a stop-gap measure to get hotplug events in place until proper implementation is done. Please leave the original interface in place so it can still be used if one wshes to do so. And what about device_driver and device structure? Are they going to be changed over to be separately allocated linked objects? If not then its enouther reason to keep original class interface - uniformity of driver model interface. -- Dmitry --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.
On Tue, 15 Mar 2005 20:08:47 +0100, Dominik Brodowski <[EMAIL PROTECTED]> wrote: > On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote: > > Then I moved the USB host controller code to use this new interface. > > That was a bit more complex as it used the struct class and struct > > class_device code directly. As you can see by the patch, the result is > > pretty much identical, and actually a bit smaller in the end. > > > > So I'll be slowly converting the kernel over to using this new > > interface, and when finished, I can get rid of the old class apis (or > > actually, just make them static) so that no one can implement them > > improperly again... > > > > Comments? > > The "old" class api _forced_ you to think of reference counting of > dynamically allocated objects, while it gets easier to get reference > counting wrong using this "simple"/"new" interface: while struct class will > always have fine reference counting, the "parent" struct [with struct class > no longer being embedded] needs to be thought of individually; and the > reference count cannot be shared any longer. > > Also, it seems to me that you view the class subsystem to be too closely > related to /dev entries -- and for these /dev entries class_simple was > introduced, IIRC. However, /dev is not the reason the class subsystem was > introduced for -- instead, it describes _types_ of devices which want to > share (userspace and in-kernel) interfaces. Exactly! I am working on input_dev class that lies between actual devices and input class devices exported by evdev, tsdev, etc. It does not have /dev entry, it is just a building block for the rest of the subsystem. evdev and the rest will be interfaces (as per driver model) for the input_dev class and will in turn continue exporting input class devices that do have /dev entries. -- Dmitry --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.
On Tue, 15 Mar 2005 11:34:15 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Mar 15, 2005 at 12:47:38PM -0500, Dmitry Torokhov wrote: > > Hi Greg, > > > > On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > So I'll be slowly converting the kernel over to using this new > > > interface, and when finished, I can get rid of the old class apis (or > > > actually, just make them static) so that no one can implement them > > > improperly again... > > > > I disagree with this last step. What I liked about the driver model is > > that once you convert (properly) subsystem to using it you > > automatically get your proper refcounting and memory gets released at > > proper time. The change as it proposed disconnects class device > > instance from the meat so separate refcounting implementation > > isneeded. This increases maintenance costs. > > I agree. The big point is that "properly" statement. _Everyone_ gets > this wrong the first time they do it. And the second. Hopefully, if > they are persistant enough, the third time they get closer, and so on... > > We need to make the driver model interface easier to use. The class > code is used by more individual drivers than the struct device, so > that's the first place to make these kinds of changes, as it is the most > necessary. > > > I always viewed class_simple as a stop-gap measure to get hotplug > > events in place until proper implementation is done. Please leave the > > original interface in place so it can still be used if one wshes to do > > so. > > No, no one has so far done the "proper implementation" and I don't blame > them. It's not simple, and it gives them a very low payback for their > time. The old interface is good and powerful and hard to use. > It takes only one proper implementation and the rest will follow. If buses and devices can be implemented properly so can be calss_devices. There is nothing magic about them. Besides, if you divorce class device and the "meat" like that most of the time you just ignoring the same problems that exist with the "meat". Class is not useful by itself, it is additional attributes and such that gets used. And with additional attributes you again have your lifetime rules, refounting and such. In effect the change does not buy you anything unless class interface is extremely limited. -- Dmitry --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.
On Tue, 15 Mar 2005 11:51:21 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > class interfaces are not going away, there's a good need for them like > you have pointed out. I'm not expecting to just delete those api > functions tomorrow, but slowly phase out the use of them over time, and > hopefully, eventually get rid of them. I think that with my USB host > controller patch, I've proved that they are not as needed as you might > think they were. > It looks to me (and I might be wrong) that USB was never really integrated into the driver model. It was glued with it but the driver model came after most of the domain was defined, and it did not get to be "bones" of the subsystem. This is why it is so easy to deatch it. -- Dmitry --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.
On Tue, 15 Mar 2005 12:35:02 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 15 March 2005 12:14 pm, Dmitry Torokhov wrote: > > > > It looks to me (and I might be wrong) that USB was never really > > integrated into the driver model. It was glued with it but the driver > > model came after most of the domain was defined, and it did not get to > > be "bones" of the subsystem. This is why it is so easy to deatch it. > > That doesn't seem accurate to me. Are you thinking maybe about > just how it uses the class device stuff? Like the rest of the > class device support (for all busses!) that did indeed come later. > You may recall that the first versions of the driver model had > more or less a big "fixme" where class devices sat... Or are > you maybe thinking about peripheral side (not host side) USB? > > But the "struct device" core of the driver model sure looks like > the bones of USB to me. Host controllers, hubs, devices, and > interfaces all use it well, behave well with hot-unplug (which > is more than many subsystems can say even in 2.6.11!), and even > handling funky cases like drivers needing to bind to multiple > interfaces on one device. That last took quite a while to land, > it involved ripping out the last pre-driver-model binding code. > David, I was not criticizing the code, not at all, I was commenting on evolution of the code (at least the way I perceive it). The fact that there is (or was until recently) pre-driver-model binding code shows that merging is still ongoing and this fact makes reversing the process easier. -- Dmitry --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
