Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
Moreover, I found many usb input device driver do not call
input_free_device() at all,
Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
Moreover, I found many usb input device driver do not call
input_free_device() at all,
Liyu wrote:
Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
I see. it is freed by input_class.release() method. So mysterious.
Liyu wrote:
Anssi Hannula wrote:
One possibility is to do that with symbol_request() and friends. That
would not be pretty though, imho.
DVB subsystem uses that currently to load frontend modules dynamically,
see dvb_attach() and dvb_frontend_detach() in
drivers/media/dvb/dvb-core/dvbdev.h
Dmitry Torokhov wrote:
On Sunday 08 October 2006 14:51, Anssi Hannula wrote:
(I didn't get Dmitry's original mail, so replying here)
[EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
Then there is issue with automatic loading of these sub-drivers. How
do they get loaded? Or we force
On Monday 09 October 2006 18:53, Anssi Hannula wrote:
Dmitry Torokhov wrote:
On Sunday 08 October 2006 14:51, Anssi Hannula wrote:
(I didn't get Dmitry's original mail, so replying here)
[EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
Then there is issue with automatic loading of
On Sunday 08 October 2006 08:41, Zephaniah E. Hull wrote:
0: If you keep all the ID identical, userspace may have the capabilities
cached. This may also cause problems, but if Dmitry or Greg calls that
a userspace bug I'll believe them and find a workaround.
Yes, I'd consider it a bug.
(I didn't get Dmitry's original mail, so replying here)
[EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
Then there is issue with automatic loading of these sub-drivers. How
do they get loaded? Or we force everything to be built-in making HID
module very fat (like psmouse got pretty fat, but
Dmitry Torokhov wrote:
Yes, I'd consider it a bug. Tearing down and re-creating input device
generates proper hotplug notifications and userspace needs to respect
them as capabilities may change even if ids stay the same. For example
playing with atkbd's scroll attribute will regenerate an
Dmitry Torokhov wrote:
Yes, I'd consider it a bug. Tearing down and re-creating input device
generates proper hotplug notifications and userspace needs to respect
them as capabilities may change even if ids stay the same. For example
playing with atkbd's scroll attribute will regenerate an
Anssi Hannula wrote:
One possibility is to do that with symbol_request() and friends. That
would not be pretty though, imho.
DVB subsystem uses that currently to load frontend modules dynamically,
see dvb_attach() and dvb_frontend_detach() in
drivers/media/dvb/dvb-core/dvbdev.h and
Dmitry Torokhov wrote:
I re-read these patches again and the main problem with the current
implementation is that it alters input devices's properties after
device has been registered and presented to userspace. That means that
hotplug users that presently can inspect device's capabilities and
12 matches
Mail list logo
