Dear Mr. Torokhov, Mr. Tissoires, Gentle Reminder: Please, update your comment/opinion/suggestion on below mail. On Mon, Feb 10, 2014 at 9:24 PM, Aniroop Mathur <aniroop.mathur@xxxxxxxxx> wrote: > Dear Mr. Torokhov, Mr. Benjamin, > Greetings! > > I sent a mail on January 25th, but still waiting for the reply. > Therefore, sending it again. > I hope to hear soon ~ > > > On Tue, Jan 21, 2014 at 3:19 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: >> Hi Aniroop, >> >> On Tue, Jan 21, 2014 at 01:34:07AM +0530, Aniroop Mathur wrote: >>> Hello Mr Tissoires >>> Greetings !! >>> >>> On Jan 20, 2014 11:54 PM, "Benjamin Tissoires" <benjamin.tissoires@xxxxxxxxx> >>> wrote: >>> > >>> > Hi Aniroop, >>> > >>> > [sorry for top posting, but I really don't know where to put this >>> regarding your answers]. >>> > >>> No problem at all. >>> In fact I am quite happy to hear from >>> Linux community again >>> Its my pleasure. >>> >>> > I _think_ I get one of the reasons you don't understand Dmitry, and why >>> Dmitry does not understand you. From the different mails, I would say that >>> you are referring to an Android platform. >>> > If it's not the case, then sorry for the noise. >>> > >>> No I am not specifically referring to >>> Android platform >>> But yes, I am from android background >>> and through android only I came up with >>> this idea. >>> >>> > So, the last time I checked with android, this system does _not_ have an >>> udev user-space daemon, which means that what you seem to be doing is >>> parsing manually the sysfs tree to retrieve the inputs and their properties. >>> > This, IMO, is a very bad idea. Parsing the entire sysfs tree is indeed >>> costly and you will have to build everything by hand. >>> > >>> No, Android also have a daemon but it is not udev daemon. There is a >>> separate daemon in android different from generic >>> udev daemon. It is different but basic is >>> still same. >>> Just like udev daemon, android daemon >>> also receives uevents from kernel >>> and creates devfs nodes for us, >>> that is /Dev/input/event1/2/3... based >>> on uevent env variables. >>> Android daemon is different from generic >>> daemon in a sense it does not see any file >>> like udev rules before creating nodes. Instead it directly create nodes as >>> per uevent env variables in the structure. >>> So without opening any extra udev rule >>> file, it create nodes. >>> So I understand it has also a limitation that it only has to be dependent >>> only on default uevents and cannot read any sysfs attribute to identify the >>> device if default uevents are not sufficient. >> >> Why can it not? >> > > It cannot because currently in android code, it does not read any > sysfs attribute. > It only reads default kernel uevents. I think functionality may be added to read > sysfs attribute also but this functionality is currently not added in > android code. > I think it is not added because in embedded system mostly there are only single > and unique devices and this manipulation might add extra time during android > initialization. > >>> >>> But the problem I am referring is for both in case of generic kernel and >>> android kernel. >> >> So far I really do not see it as generic kernel problem since we do have >> existing infrastructure in userspace that is quite efficient. >> > > The existing way is also there but there is always a scope of improvement. > Tell me which is more efficient ? > 1. existing method in which udev opens and read udev files for setting name > or > 2. Directly set name without doing extra calculations > > Its correct existing method will also do the same task but why not to use > more efficient way. > I just want to improve efficiency. > > >>> >>> > On regular distros, we use udev. This daemon builds its device database >>> from the events generated by the kernels directly (the uevents). Once the >>> events are emitted, we never (except for some user-space drivers) use them >>> in the kernel drivers (at least, I never saw that). >>> > >>> > So if you want to create symlinks, then indeed, you just add 2 or 3 rules >>> in /etc/udev/rules.d, and then the user space (and the system integrator) >>> can see the different devices with the "correct" symlink. >>> > However, the kernel developer will never see them (and especially in the >>> ->probe callback). However, the user-space tools which receives the udev >>> events (emitted from udev, not the kernel this time) can easily retrieve >>> many information from the event. Just run "udevadm info --export-db" on a >>> regular Linux, and you will see that the device which presents the event >>> node (/dev/input/eventX) has all the requirements to identify itself (VID, >>> PID, path, etc...) >>> > >>> Yes udev gives so many uevents but as I checked through logs specifically >>> in case of /Dev/input/event1/2/3/4....it does not give sufficient uevents >>> to identify the device. >>> As I found in logs it gives only 7 env variable like action, subsystem, Dev >>> name, Dev path, major, minor and seq number. >>> It does not give vendor Id or pid. >>> Now with these uevent we cannot identify the input device whether its >>> accelerometer or touchscreen. Can we ?? >> >> While information sent in uevent emitted for creation of event device >> might not be enough to identify and classify input device you can: >> >> 1. Capture udevent sent a few moments earlier for the input device >> itself, or >> >> 2. Read /sys/class/$DEVNAME/device/uevent to retrieve input device's >> uevent data: >> >> [dtor@dtor-d630 work]$ cat /sys/class/input/event6/uevent >> MAJOR=13 >> MINOR=70 >> DEVNAME=input/event6 >> [dtor@dtor-d630 work]$ cat /sys/class/input/event6/device/uevent >> PRODUCT=11/2/8/300 >> NAME="AlpsPS/2 ALPS DualPoint TouchPad" >> PHYS="isa0060/serio1/input0" >> PROP=8 >> EV=b >> KEY=e420 70000 0 0 0 0 >> ABS=260800001000003 >> MODALIAS=input:b0011v0002p0008e0300-e0,1,3,k110,111,112,145,14A,14D,14E,14F,ra0,1,18,2F,35,36,39,mlsfw >> [dtor@dtor-d630 work]$ >> >> That should give you plenty data to work with. Yes, the 2nd option >> involves additional filesystem operations, but this is sysfs (so you are >> not hitting real media) and you only need a few (open, read, and close) >> per device. > > Yes this method can surely solve the task , but not the purpose. > My query is why not to use more efficient way when we can ? > ( Already discussed this way is backward compatible and is optional to use) > > > > Apart from above, Could you please tell me the role/use of init_name variable, > which is defined in "struct device" ? > (I think, it is also used to set name of device node) > > Thanks, > Aniroop Mathur > >> >> Thanks. >> >> -- >> Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
