Dmitry Torokhov wrote:
>> +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
On Tue, 3 Apr 2007, Jiri Kosina wrote:
On Tue, 3 Apr 2007, Li Yu wrote:
May be, we need some means to change blacklist in runtime.
Paul Walmsley (added to CC) sent me patches some time ago that among other
things implemented possibility to modify the hid_blacklist[] in runtime.
The patches
Jiri Kosina wrote:
On Wed, 4 Apr 2007, Adam Kropelin wrote:
On Apcupsd we've recently introduced a libusb-based driver that does
all HID parsing in userspace. Not only does that free us from
hiddev, it also frees us from the umpteen other proprietary HID
interfaces across various platforms.
On Wed, 4 Apr 2007, Adam Kropelin wrote:
> > hiddev will have to stay for quite some time, exactly because of
> > backward compatibility with userspace applications/drivers that use it
> > (I am not aware of many of them though, but apparently there are
> > some).
> Apcupsd is the one on my
Dmitry Torokhov wrote:
>>> +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(_lock);
>>> + tl = hid_transports[hid->bus];
>>> +
Dmitry Torokhov wrote:
>> +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
Dmitry Torokhov wrote:
+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
Dmitry Torokhov wrote:
+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))
+
Dmitry Torokhov wrote:
+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 =
On Wed, 4 Apr 2007, Adam Kropelin wrote:
hiddev will have to stay for quite some time, exactly because of
backward compatibility with userspace applications/drivers that use it
(I am not aware of many of them though, but apparently there are
some).
Apcupsd is the one on my mind, but I
Jiri Kosina wrote:
On Wed, 4 Apr 2007, Adam Kropelin wrote:
On Apcupsd we've recently introduced a libusb-based driver that does
all HID parsing in userspace. Not only does that free us from
hiddev, it also frees us from the umpteen other proprietary HID
interfaces across various platforms.
On Tue, 3 Apr 2007, Jiri Kosina wrote:
On Tue, 3 Apr 2007, Li Yu wrote:
May be, we need some means to change blacklist in runtime.
Paul Walmsley (added to CC) sent me patches some time ago that among other
things implemented possibility to modify the hid_blacklist[] in runtime.
The patches
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 :)
> >
> >
>
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 ;)
so far,
Jiri Kosina wrote:
On Wed, 4 Apr 2007, Adam Kropelin wrote:
I apologize for picking up this thread late and asking what may be a
question with an obvious answer... Will hiddev still exist after
hidraw and the HID bus redesign work is done? I have a
widely-deployed userspace app that relies on
On Wed, 4 Apr 2007, Adam Kropelin wrote:
> I apologize for picking up this thread late and asking what may be a
> question with an obvious answer... Will hiddev still exist after hidraw
> and the HID bus redesign work is done? I have a widely-deployed
> userspace app that relies on hiddev, and
Jiri Kosina wrote:
On Tue, 3 Apr 2007, Li Yu wrote:
What's the position of hidraw? It only is used when all other driver
is not usable on some report? or, it should be stick every working
device.
Current implementation (as you can see it in -mm or in my hid.git
tree) is creating hidraw
Hi Jiri,
> > What's the position of hidraw? It only is used when all other driver is
> > not usable on some report? or, it should be stick every working device.
>
> Current implementation (as you can see it in -mm or in my hid.git tree) is
> creating hidraw interface for just every HID
Hi Jiri,
What's the position of hidraw? It only is used when all other driver is
not usable on some report? or, it should be stick every working device.
Current implementation (as you can see it in -mm or in my hid.git tree) is
creating hidraw interface for just every HID
Jiri Kosina wrote:
On Tue, 3 Apr 2007, Li Yu wrote:
What's the position of hidraw? It only is used when all other driver
is not usable on some report? or, it should be stick every working
device.
Current implementation (as you can see it in -mm or in my hid.git
tree) is creating hidraw
On Wed, 4 Apr 2007, Adam Kropelin wrote:
I apologize for picking up this thread late and asking what may be a
question with an obvious answer... Will hiddev still exist after hidraw
and the HID bus redesign work is done? I have a widely-deployed
userspace app that relies on hiddev, and I'm
Jiri Kosina wrote:
On Wed, 4 Apr 2007, Adam Kropelin wrote:
I apologize for picking up this thread late and asking what may be a
question with an obvious answer... Will hiddev still exist after
hidraw and the HID bus redesign work is done? I have a
widely-deployed userspace app that relies on
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 ;)
so far, the
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
Jiri Kosina wrote:
> Current implementation (as you can see it in -mm or in my hid.git tree) is
> creating hidraw interface for just every HID device/interface. But this
> will get changed before merge.
>
> Passing just everything to hidraw is not a good option, as this could lead
> to
On Tue, 3 Apr 2007, Li Yu wrote:
> May be, we need some means to change blacklist in runtime.
Paul Walmsley (added to CC) sent me patches some time ago that among other
things implemented possibility to modify the hid_blacklist[] in runtime.
The patches had some issues which Paul said will fix
On Tue, 3 Apr 2007, Li Yu wrote:
> What's the position of hidraw? It only is used when all other driver is
> not usable on some report? or, it should be stick every working device.
Current implementation (as you can see it in -mm or in my hid.git tree) is
creating hidraw interface for just
On Tue, 3 Apr 2007, Li Yu wrote:
What's the position of hidraw? It only is used when all other driver is
not usable on some report? or, it should be stick every working device.
Current implementation (as you can see it in -mm or in my hid.git tree) is
creating hidraw interface for just every
On Tue, 3 Apr 2007, Li Yu wrote:
May be, we need some means to change blacklist in runtime.
Paul Walmsley (added to CC) sent me patches some time ago that among other
things implemented possibility to modify the hid_blacklist[] in runtime.
The patches had some issues which Paul said will fix
Jiri Kosina wrote:
Current implementation (as you can see it in -mm or in my hid.git tree) is
creating hidraw interface for just every HID device/interface. But this
will get changed before merge.
Passing just everything to hidraw is not a good option, as this could lead
to confusion and
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
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
Nicolas Mailhot wrote:
>> Er, I also want to know what are drawbacks of "flip-flopping" ?
>>
>
> This will cause major havoc as soon as hot-plugging and apps listening to
> HAL events (xorg eventually) enter in play.
>
>
~_~
It really need some extra works in user space, but I do not
Marcel Holtmann wrote:
> The cleanest solution without a layer violation is that you can
> register a driver for a specific VID/PID and then report id (one or
> more). All
> reports with ids that we don't have a special driver for are handled by
> the default HID->input driver or handed over to
Hi Jiri,
> > I like this idea, but it might not solve the case where you have parts
> > of the driver in kernel space and other parts in user space. For example
> > the control of a LCD display on the keyboard. However in most cases
> > registering drivers for a report id should be enough.
>
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
On Mon, 2 Apr 2007, Marcel Holtmann wrote:
> I like this idea, but it might not solve the case where you have parts
> of the driver in kernel space and other parts in user space. For example
> the control of a LCD display on the keyboard. However in most cases
> registering drivers for a
Hi Li,
> > JFYI the preliminary version of the hidraw interface is now in the
> > hid/usbhid git tree, and has also been in a few recent -mm kernels
> > already.
> >
> >
> The shadow driver support works now.
>
> The most largest problem is HID/Bluetooth can not work now. And, I have
> no
Hi Dmitry,
> > 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.
> Er, I also want to know what are drawbacks of "flip-flopping" ?
This will cause major havoc as soon as hot-plugging and apps listening to
HAL events (xorg eventually) enter in play.
--
Nicolas Mailhot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Jiri Kosina wrote:
I agree. I am aware of devices for which just inspecting the parsed data
would be OK (some keyboards with usage mappings which are not defined by
HUT, for example), but also of devices which require special handling on
the report level - Robert Marquardt pointed me in a
On Mon, 2 Apr 2007, Dmitry Torokhov wrote:
> > static void my_driver_hid_report(struct hid_device *hid, u8 *data,
> > int size)
> > {
> > if (special_processing_needed(data)) {
> > do_special_processing(...);
> >
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
On Mon, Apr 02, 2007 at 03:07:29PM +0800, Li Yu wrote:
> Dmitry Torokhov wrote:
> >
> > 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
Dmitry Torokhov wrote:
>
> 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.
>
Dmitry Torokhov wrote:
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.
Hi, I
On Mon, Apr 02, 2007 at 03:07:29PM +0800, Li Yu wrote:
Dmitry Torokhov wrote:
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
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
On Mon, 2 Apr 2007, Dmitry Torokhov wrote:
static void my_driver_hid_report(struct hid_device *hid, u8 *data,
int size)
{
if (special_processing_needed(data)) {
do_special_processing(...);
Jiri Kosina wrote:
I agree. I am aware of devices for which just inspecting the parsed data
would be OK (some keyboards with usage mappings which are not defined by
HUT, for example), but also of devices which require special handling on
the report level - Robert Marquardt pointed me in a
Er, I also want to know what are drawbacks of flip-flopping ?
This will cause major havoc as soon as hot-plugging and apps listening to
HAL events (xorg eventually) enter in play.
--
Nicolas Mailhot
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Hi Dmitry,
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
Hi Li,
JFYI the preliminary version of the hidraw interface is now in the
hid/usbhid git tree, and has also been in a few recent -mm kernels
already.
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any bluetooth
On Mon, 2 Apr 2007, Marcel Holtmann wrote:
I like this idea, but it might not solve the case where you have parts
of the driver in kernel space and other parts in user space. For example
the control of a LCD display on the keyboard. However in most cases
registering drivers for a report id
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
Hi Jiri,
I like this idea, but it might not solve the case where you have parts
of the driver in kernel space and other parts in user space. For example
the control of a LCD display on the keyboard. However in most cases
registering drivers for a report id should be enough.
the
Marcel Holtmann wrote:
The cleanest solution without a layer violation is that you can
register a driver for a specific VID/PID and then report id (one or
more). All
reports with ids that we don't have a special driver for are handled by
the default HID-input driver or handed over to hidraw
Nicolas Mailhot wrote:
Er, I also want to know what are drawbacks of flip-flopping ?
This will cause major havoc as soon as hot-plugging and apps listening to
HAL events (xorg eventually) enter in play.
~_~
It really need some extra works in user space, but I do not think this
is
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
On Monday 02 April 2007 21:15, Li Yu wrote:
If we don't use flip-flopping means, the common driver and specific
driver concepts also don't need. They are completely same driver for HID
bus, just one without some hooks, another without.
Exactly. I am glad we are getting on the same page.
--
On 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
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
Jiri Kosina wrote:
> On Fri, 30 Mar 2007, Dmitry Torokhov wrote:
>
>
>> 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)
>> {
Jiri Kosina wrote:
On Fri, 30 Mar 2007, Dmitry Torokhov wrote:
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
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
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
On Fri, 30 Mar 2007, Dmitry Torokhov wrote:
> 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
On Fri, 30 Mar 2007, Dmitry Torokhov wrote:
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
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
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
Dmitry Torokhov wrote:
> 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
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,
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
>>
On Thu, 29 Mar 2007, Li Yu wrote:
> The last word is a question, what's the future of hiddev? It will merge
> into hidraw later? I think so, but can't sure.
Hi Li,
no, it won't, it doesn't provide compatible interface for purpose.
hiddev has currently the following drawbacks:
-
On Thu, 29 Mar 2007, Li Yu wrote:
The last word is a question, what's the future of hiddev? It will merge
into hidraw later? I think so, but can't sure.
Hi Li,
no, it won't, it doesn't provide compatible interface for purpose.
hiddev has currently the following drawbacks:
- USB-transport
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
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
Dmitry Torokhov wrote:
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
Jiri Kosina wrote:
> JFYI the preliminary version of the hidraw interface is now in the
> hid/usbhid git tree, and has also been in a few recent -mm kernels
> already.
>
>
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any
On Wed, 28 Mar 2007, Dmitry Torokhov wrote:
> 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.
Agreed. This is actually what I meant in the original mail, but phrased it
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
On Wed, 28 Mar 2007, Li Yu wrote:
> I also sense this. we may need not such a complete layer at all.
> Although the work of hiddev/rawdev support does not begin, however, as
> the design, especially, let hiddev/rawdev live in HIDAL, I think this
> may need a bit of abstract of transport layer.
On Wed, 28 Mar 2007, Li Yu wrote:
I also sense this. we may need not such a complete layer at all.
Although the work of hiddev/rawdev support does not begin, however, as
the design, especially, let hiddev/rawdev live in HIDAL, I think this
may need a bit of abstract of transport layer.
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
On Wed, 28 Mar 2007, Dmitry Torokhov wrote:
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.
Agreed. This is actually what I meant in the original mail, but phrased it
Jiri Kosina wrote:
JFYI the preliminary version of the hidraw interface is now in the
hid/usbhid git tree, and has also been in a few recent -mm kernels
already.
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any bluetooth
Marcel Holtmann wrote:
> please don't take the transport layers into account when designing the
> HID bus. They have nothing to do with the upper layer. Especially the
> upper layer shouldn't care at all if the actual HID reports are sent
> over USB or Bluetooth.
>
>
I am sorry for I see this
Marcel Holtmann wrote:
please don't take the transport layers into account when designing the
HID bus. They have nothing to do with the upper layer. Especially the
upper layer shouldn't care at all if the actual HID reports are sent
over USB or Bluetooth.
I am sorry for I see this mail so
Hi Li,
> --
> HID bus design overview.
> --
>
> A. Terms.
>
> The device of an driver: this mean the device that this driver matched.
>
> B. Design.
>
> As we discussed before, The entire HID subsystem is
Hi Li,
--
HID bus design overview.
--
A. Terms.
The device of an driver: this mean the device that this driver matched.
B. Design.
As we discussed before, The entire HID subsystem is divided into
90 matches
Mail list logo
