either
coordinate with Jiri so that no effort is wasted, or you can just send me
a patch with simple quirks addition, and it will get converted into hidbus
driver later.
Thanks,
--
Jiri Kosina
SUSE Labs
t; #include
> #include
> +#include
> +#include
Why is linux/sched.h needed? Maybe you want to include workqueue.h
instead?
Thanks,
--
Jiri Kosina
SUSE Labs
ame can be changed at any time later.
Thanks for addressing the other issues,
--
Jiri Kosina
SUSE Labs
r userspace) relies on the
exact name of this module. Or am I wrong?
--
Jiri Kosina
7xx (like we have for the keyboard).
And is there any issue with that?
Thanks,
--
Jiri Kosina
SUSE Labs
with the one from jornada720_ts driver?
Also, while you are at it, maybe it would be worth to rename the driver?
(hp6xx instead of hp680).
--
Jiri Kosina
SUSE Labs
bug=1' parameter. Then perform all the operations that
don't seem to work (i.e. press the non-working buttons, etc), and send me
the annotated dmesg output (i.e. "this appeared when I pressed that
button", etc).
Thanks,
--
Jiri Kosina
SUSE Labs
in HID (see commit a45d82d19a6c2a717bcc33cff243199b77fa0082), so it would
require some trivial modifications.
Thanks!
--
Jiri Kosina
SUSE Labs
On Tue, 12 Feb 2008, Tobias Müller wrote:
> Add usb product-id to hid-quirks for detection of 3rd generation macbook
> keyboard and the new apple desktop keyboard.
Hi Tobias,
the patch is mangled (wordwrapped by your mailer), could you please fix
that up and resend?
Thanks a lot,
--
s going to be
phased out, and [EMAIL PROTECTED] is going to replace it.
--
Jiri Kosina
SUSE Labs
book_fn_keys[], as that would break other
models. These models might possibly need a different table.
As you are obviously able to do C coding, do you think you could prepare
fully working and tested patch and send it to me?
Thanks,
--
Jiri Kosina
On Tue, 15 Jan 2008, Jiri Kosina wrote:
> > I've got a third-generation MacBook and the Fn-Key is not working,
> > althought CONFIG_USB_HIDINPUT_POWERBOOK is set to y.
> > I checked drivers/hid/usbhid/hid-quirks.c and found, that the device_id
> > of my keyboard
e USB_DEVICE_ID_APPLE_GEYSER4_ISO 0x0221
> and also everything was working.
Thanks for your information. I will add these new IDs into my tree.
--
Jiri Kosina
es do I need to apply the new quirks handling on top of
> 2.6.23 or .24? I would like to test that stuff as well then.
You can just grab the 'mm' branch of my git tree, that should always
contain the most up-to-date state.
Thanks,
--
Jiri Kosina
from CC, re-added). Jan?
Thanks,
--
Jiri Kosina
On Mon, 7 Jan 2008, Jonas Delrue wrote:
> The mouse is not in lsusb list but I found the data using hidd --show. Seems
> like my product id is 0x0701.
> 0:12:5A:64:50:78 Microsoft Mouse [045e:0701] connected
Hi Jonas,
could you please verify whether the patch below, when applied on top of
rec
usage code values being reported properly.
--
Jiri Kosina
org allows one to use pressure sensitivity, but has
> the aforementioned button problem. The two are not compatible.
I don't fully understand your descirption, sorry. So it is OK to handle
this device with HID driver?
--
Jiri Kosina
erly w/ the patch applied using the js_x driver.
> Just blacklisted it from usbhid and added the usb id to kbtab.c
Hi John,
I will queue the addition of HID blacklist entry for 2.6.25. The ktab
change will be picked by Dmitry I guess.
Thanks,
--
Jiri Kosina
.23.1
> > Looks like this is a regression
> No response from developers
Hi,
it is assigned to '[EMAIL PROTECTED]', so I didn't
notice, it's as simple as that.
--
Jiri Kosina
27;hiddev_ioctl' makes integer from pointer without a cast
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Hi Stephen,
I already have this fixed in my tree, sorry.
Thanks a lot,
--
Jiri Kosina
push a few fixes to Linus probably today, so I'll take
your patch through my tree together with other fixes.
Thanks!
--
Jiri Kosina
he redundant
NULL-ptr checks.
Thanks,
--
Jiri Kosina
for the button and the button doesn't send HID-style
> reports.
The only reason I was talking about it in terms of being a HID device was
because Thorsten stated that usbhid driver gets bound to it.
Now that we know that Torsten was having different HW, my point is of
course invalid :)
Thanks,
--
Jiri Kosina
ut_disconnect and who knows what will happen after
> that.
You are of course right, stupid me. I won't commit anything before first
morning coffee any more.
Thanks a lot.
--
Jiri Kosina
On Mon, 29 Oct 2007, Dirk Hohndel wrote:
> [INPUT] hidinput_connect incorrectly ignored return value from
> input_register_device
> Signed-off-by: Dirk Hohndel <[EMAIL PROTECTED]>
Will apply, thanks a lot.
--
Jiri Kosina
ny functionality you wish (probably
suspend/resume cycle is needed here?).
If the device is claimed by usbhid driver (because its descriptor probably
states that it's HID-compliant device) and should be claimed by another
driver, it's necessary to add it to usbhid blacklist -- just let me know.
--
Jiri Kosina
It would be great if you could redo the patch to fit into this
picture and send it to me again.
Thanks,
--
Jiri Kosina
SUSE Labs
On Thu, 11 Oct 2007, Dmitry Torokhov wrote:
> I'd rather HID part go through your tree. Here is is split out.
Hi Dmitry,
thanks, I will take this through my tree. I am planning to send the pull
request to Linus by the end of this week.
--
Jiri Kosina
27;s
tree has them pulled through git-input.patch for example.
Thanks,
--
Jiri Kosina
tch if you want to.
Thanks,
--
Jiri Kosina
to suspend support.
--
Jiri Kosina
is not fully
> transparent. The LEDs are switched off when then keyboard is suspended.
> Should I now implement a mode where active LEDs block suspension and if
> so, how do I switch it on?
Maybe module parameter of usbhid could be used to specify the desired
behavior?
Thanks,
--
Jiri Kosina
On Thu, 27 Sep 2007, Mariusz Kozlowski wrote:
> It looks like hidraw_connect() is leaking memory in case of failure.
> Also it should return -ENOMEM when kzalloc fails.
Mariusz,
good catch, will apply to me tree.
Thanks,
--
Jiri Kosina
SUSE Labs
_usage().
Anyway, I applied your cleanup patch, thanks.
--
Jiri Kosina
SUSE Labs
ake up thinking that the key is still pressed?
If the release event didn't happen before the machine went to suspend, I'd
say so.
--
Jiri Kosina
keyboard has keys pressed?
Hi Oliver,
HID doesn't keep any permanent state by itself. If you want to know
whether a given key is currently pressed or not, you'd have to inspect the
bitfields inside input_dev*, I am afraid.
--
Jiri Kosina
7; parameter
Then you'd get HID debugging data from the kernel. If you'd send them to
me, I can have a look whether the release event arrived from the mouse or
not.
Thanks,
--
Jiri Kosina
esting was done with a Köng Gaming
> gamepad.
Hi Anssi,
thanks a lot for your patch. Unfortunately, it is word-wrapped and
whitespace-damaged, could you please respin it and resend it?
Thanks,
--
Jiri Kosina
> > HID_QUIRK_IGNORE },
> > { USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302, HID_QUIRK_IGNORE
> > },
> A minor detail, but the CMEDIA entry should be sorted alphabetically,
> as the comment says. See below.
I have already fixed up the Alfred's patch when merging it into my tree,
but thanks anyway!
--
Jiri Kosina
id quirk list in my tree. The driver
itself should be submitted to Dmitry.
Thanks,
--
Jiri Kosina
fs image, not from /lib/modules of my root partition. I updated
> the initramfs image and all is good!
BTW when you are ready with the CM109 driver, please don't forget to send
me a patch which will add the device to the HID blacklist.
Thanks,
--
Jiri Kosina
s to the device?
If so, could you please compile with CONFIG_HID_DEBUG enabled and modprobe
the usbhid module with 'debug=1' parameter and send me the kernel output?
--
Jiri Kosina
e look at
http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=shortlog;h=upstream
--
Jiri Kosina
SUSE Labs
would mean the change in
key state.
--
Jiri Kosina
input_event(input, usage->type, usage->code, value);
if ((field->flags & HID_MAIN_ITEM_RELATIVE) && (usage->type == EV_KEY))
--
Jiri Kosina
n behind it?
I find the blacklist sorted by quirk type more convenient - we typically
want to know "who has this particular quirk", but we generally don't care
"what quirks does this particular vendor have".
--
Jiri Kosina
gt; HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE }
> be:
> {..., ..., HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_HAS_FN }
This could be a possible cleanup for hid_blacklist[], if you are going to
make a patch I will happily accept it.
Thanks,
--
Jiri Kosina
re any error messages reported when the hang occurs.
(*) with the latest vanilla kernel (2.6.23-rc1 and later) CONFIG_HID_DEBUG
defaults to 'y', but you have to pass 'debug=1' parameter to receive the
debugging output).
Thanks,
--
Jiri Kosina
SUSE Labs
0853.114223, type 1 (Key), code 30 (A), value 0
Event: time 1182930853.114227, -- Report Sync
I don't think this is what you want. We could alternatively for example
remember all the previous states of all the KEY controls and report
scancodes only of those which got changed, this would solve this issue.
**
However, this might look like an overhead.
--
Jiri Kosina
On Sun, 22 Jul 2007, Jiri Slaby wrote:
> > --- a/drivers/hid/usbhid/hid-core.c
> > +++ b/drivers/hid/usbhid/hid-core.c
> > @@ -743,7 +743,7 @@ static struct hid_device *usb_hid_configure(struct
> > usb_interface *intf)
> > hid->quirks = quirks;
> >
> > if (!(usbhid = kzalloc(sizeof(stru
ress, and ffmvforce utilities).
> > Thanks you both for doing patches so fast :)
> Thank you for testing. Jiri, please consider adding to your tree.
Hi,
sorry for late reply, I was offline on vacation.
I have fixed a minor typo in the patch changelog and applied it to my
tree, thanks a lot.
--
Jiri Kosina
SUSE Labs
thanks a lot for noticing this, I have queued your patch in HID tree.
(and sorry for late reply, I was offline on vacation for some time).
--
Jiri Kosina
stian,
I have slightly modified your patch (let's keep the hid_blacklist[]
properly sorted) and applied it into my tree.
Thanks,
--
Jiri Kosina
r, we should remove the ignore quirk.
> I think that the blacklist entry for USB_DEVICE_ID_APPLE_IR should be
> removed at least as long as the appleir.patch is not part of the
> mainline kernel.
Would you care to send me a patch with proper changelog and Signed-off-by
line?
Thanks,
--
Jiri Kosina
n output reports.
> Does not seem to work correctly with 2.6.22-rc1, either.
OK, now I see. It worked due to luck previously, and Diego's fix is a
proper one - the value needs to be set explicitly, we can't rely on bits
in the output report being set previously to any known value.
Thanks,
--
Jiri Kosina
(for example 2.6.22-rc1)? That
should be the definitive fix for all issues with zeroing of unused bits in
output reports.
Thanks,
--
Jiri Kosina
get back to you in a few days :)
Hi Anssi,
did you make any progress here please? I am going to merge the patch,
still I'd be understand what caused it (on the other hand from Diogo's
last comment it doesn't seem 100% certain that we cased it somewhere
around 2.6.20).
Thanks,
--
Jiri Kosina
operly
into my tree, but I would be curious what broke it, to double check that
we didn't break anything else along with it.
Thanks,
--
Jiri Kosina
1.
Hi Anssi,
do you have any idea what caused this to happen in 2.6.21 and not in
earlier versions?
--
Jiri Kosina
SR: 4000
> [ 76.487763] TASK = dff119f0[83] 'khubd' THREAD: dff12000
> [ 76.487947] GPR00: c02c1ca8 dff13e40 dff119f0 c0536020 c04687e0 0006
> 0011
> [ 76.488930] GPR08: 0002 6b6b6b6b 22004242 dff12000
>
> [ 76.489915] GPR16: df0ea6c8 0002
> df0ea6e0 0001
> [ 76.490931] GPR24: df642518 df64280c df642da0 df0ea098 df0ea080 6b6b675b
> dec5556c dec0
> [ 76.492363] NIP [c02c1cbc] evdev_disconnect+0x94/0xf4
> [ 76.493057] LR [c02c1ca8] evdev_disconnect+0x80/0xf4
> [ 76.493725] Call Trace:
> [ 76.494291] [dff13e40] [c02c1ca8] evdev_disconnect+0x80/0xf4 (unreliable)
> [ 76.495063] [dff13e60] [c02be900] input_unregister_device+0x98/0x130
> [ 76.495799] [dff13e70] [c02e2140] hidinput_disconnect+0x40/0x80
> [ 76.496518] [dff13e90] [c02e6328] hid_disconnect+0x78/0xd4
> [ 76.497220] [dff13eb0] [c0299c80] usb_unbind_interface+0x48/0x90
> [ 76.497950] [dff13ed0] [c021e6e4] __device_release_driver+0x98/0xc4
> [ 76.498686] [dff13ee0] [c021ec4c] device_release_driver+0x50/0x84
> [ 76.499409] [dff13ef0] [c021deb0] bus_remove_device+0x84/0xb0
> [ 76.500132] [dff13f00] [c021ba24] device_del+0x274/0x324
> [ 76.500834] [dff13f20] [c02970c8] usb_disable_device+0x80/0x110
> [ 76.501561] [dff13f40] [c029331c] usb_disconnect+0xc4/0x150
> [ 76.502269] [dff13f70] [c0293a74] hub_thread+0x354/0xac4
> [ 76.502965] [dff13fd0] [c00435ec] kthread+0x4c/0x88
> [ 76.503656] [dff13ff0] [c001433c] kernel_thread+0x44/0x60
> [ 76.504367] Instruction dump:
> [ 76.504960] 7fc3f378 4bffb645 387f0040 3881 38a1 38c0 4bd66b1d
> 813f005c
> [ 76.505905] 480c 4bdc5021 813d0410 3ba9fbf0 <801d0410> 2f80
> 419e0008 7c00022c
>
>
--
Jiri Kosina
LE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> +
> diff --git a/drivers/input/joystick/xboxrcvr.h
> b/drivers/input/joystick/xboxrcvr.h
> new file mode 100644
> index 000..685dbff
> --- /dev/null
> +++ b/drivers/input/joystick/xboxrcvr.h
> @@ -0,0 +1,72 @@
> +/*
> + * Xbox wireless receiver input device driver for Linux - v0.0.1
> + *
> + * Copyright (c) 2007 Brian Magnuson <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * 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
> + *
> + */
> +
> +#ifndef __XBOXRCVR_h
> +#define __XBOXRCVR_h
> +
> +/* driver internals ***/
> +#ifdef __KERNEL__
> +
> +#include
> +#include
> +
> +/** driver description and version /
> +#define DRIVER_VERSION "v0.0.1"
> +#define DRIVER_AUTHOR "Brian Magnuson"
> +#define DRIVER_DESC"Driver for wireless xbox360 controllers"
> +
> +#define XBOXRCVR_PKT_LEN 32
> +
> +/* the device struct **/
> +struct usb_xboxrcvr {
> + struct input_dev *dev; /* input device interface */
> + struct usb_device *udev;/* usb device */
> +
> + struct urb *irq_in; /* urb for int. in report */
> +
> + int id;
> + int gamepad_present;
> + int gamepad_registered;
> + int headset_present;
> +
> + struct usb_interface *intf;
> +
> + struct work_struct idev_build;
> + struct work_struct idev_teardown;
> +
> + unsigned char *idata; /* input data */
> + dma_addr_t idata_dma;
> +
> + int open; /* open to the input layer */
> +
> + char phys[65]; /* physical input dev path */
> + char uniq[5]; /* unique identifier */
> +};
> +
> +/* for the list of know devices */
> +struct xboxrcvr_device {
> + u16 idVendor;
> + u16 idProduct;
> + char *name;
> +};
> +
> +#endif /* __KERNEL__ */
> +
> +#endif /* __XBOXRCVR_h */
>
--
Jiri Kosina
ed int
everywhere)?
Thanks,
--
Jiri Kosina
SUSE Labs
Hi,
recently I have been looking into bugreports against xpad driver - the
complaints were that for some devices (I am aware of at least
0x045e/0x028e and 0x0738/0x4716), the driver doesn't work at all even if
the device ids are added into xpad_device[] array. In fact the driver
doesn't even g
wheel
produces no input events at all, i.e. mapping of HID_GD_Z to REL_HWHEEL
(HID_QUIRK_MIGHTYMOUSE quirk) is needed.
--
Jiri Kosina
he very same quirk as USB version.
Recent kernels contain a duplication of the USB quirk for Bluetooth
version of the mouse, in order to make the scrollwheel work. But
2.6.20.4+bluez patches don't provide this quirk yet.
What product/vendor ids does your mightymouse have?
Thanks,
--
Jiri Kosina
what the
original code does, and that is correct.
After you patch, the usb_hid_configure() proceeds both for Wacom and
IOWarrior devices, just leaving the quirks mask empty. But that's not what
it should do, right?
Thanks,
--
Jiri Kosina
luetooth mouse, since
2.6.21-rc6. It would be nice if you could verify that the Bluetooth
version works fine with this kernel (or any newer).
Thanks,
--
Jiri Kosina
SUSE Labs
eally somehow don't think that
having to duplicate every new quirk is a nice solution. Joel, is there any
specific reason why configfs doesn't allow this please?
Or we could reconsider going back to the idea of using sysfs.
Thanks a lot,
--
Jiri Kosina
SUSE Labs
dware in question to test with. This X
configuration is of course perfectly valid.
Bart, as you wrote the original patch which inverted the wheel, could you
provide some more information please? It seems to me that you guys have
different versions of mightymouse ... but I wouldn't believe they would
have the same PID :)
Thanks,
--
Jiri Kosina
SUSE Labs
', which will be used for the purpose of configfs.
This way we would not have to duplicate the entries anywhere. All the
other fields you are currently keeping in hid_quirk_types[] could be made
implicitly default, only 'name' is the one that matters, right?
Thanks,
--
Jiri Kosina
On Wed, 11 Apr 2007, Jiri Kosina wrote:
> - [7/7] I agree with using configfs. What is quite unfortunate is that
> adding a new quirk requires now another place that it is necessary to
> modify - forgetting to do it and keeping configfs values out-of-sync
> seems rather eas
able to come with an idea
immediately how to make it better.
Thanks,
--
Jiri Kosina
SUSE Labs
trial and error? How would I find what the report for FF_SPRING
>should look like?
You can monitor how other already existing drivers behave, and try to
simulate the behavior in your driver.
--
Jiri Kosina
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
--
Jiri Kosina
udev settles down. This is not a nice API to provide. Will
try to think of some solution which would have reasonable
nastiness/functionality ratio.
--
Jiri Kosina
;input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"
and the let Xorg use /dev/input/appletouchpad, which will always be a
symlink to the correct device.
--
Jiri Kosina
ver-generalized to
me.
Anyway, I think that the possibility to modify the hid_blakclist[] in
runtime could be useful. If you agree with the above and would care to
redo the pathces in such way, I would be inclined to merge them.
Thanks,
--
Jiri Kosina
27;hid_quirks' which allows quirks to be modified at boot or
> module load-time. These quirks can also be reviewed and configured at
> runtime via a procfs file, /proc/usbhid/device_quirks.
This is unfortunately also not going to fly - the general rule of thumb is
that no new entries
lmost certainly X bug.
Thanks,
--
Jiri Kosina
me bound to usbhid driver (you can check this in
/sys)? When the quirk works correctly, only the keyboard interface should
be bound to usbhid driver. Please check the binding both before and after
suspend/resume cycle, and let me know.
Thanks,
--
Jiri Kosina
On Wed, 21 Feb 2007, Adrian Bunk wrote:
> Every file should include the headers containing the prototypes for
> it's global functions.
Applied, thanks.
--
Jiri Kosina
82 matches
Mail list logo
