From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bryan W. Headley" Date: Tue, 17 Feb 2004 00:54:16 +0000 Subject: Hotplug-- who notifies whom of what? Message-Id: <40316638.9060501@earthlink.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Greg, Regards to Aiptek USB tablets... I'm trying to figure out a strategy for hotplugging. 1) The tablet is mapped to the input device system. a) Because the order in which drivers complete loading/registering is not deterministic (e.g., mouse driver spawns thread), I do not know with certainty that the tablet will always be mapped to /dev/input/event27. So, configuration files of certain (XFree) applications that require that the path be known and static enough to put in a text file. b) No problem. So I whip up a startup process that finds the tablet and creates a softlink that XF86Config-4 can refer to. That is relying on the sysvinit system, and is wrong insofar as it knows there's a tablet owned by the user (I'm thinking of RH, Mandrake, et al, quality scripts, here. Not little one-liners we all write.) 2) In case of a hotplug event, e.g., the tablet being disconnected, I really should get rid of the softlink... a) But is that the domain of a script in hotplug? 3) In case of hotplug-connect, I should re-create the softlink. a) Again, in the hotplug domain? I ask because I have an rc script that does the same thing on boot-up, and I'd rather not have things cross-referenced between two packages. b) Plus, what I do to find the aiptek tablet COULD BE scriptable on 2.6, would be hard to script on 2.4. Anyway, it's not a script now, it makes ioctl calls. 4) Moving upstream... X needs to be notified that device 'x', that it's using for input, has been plugged/unplugged. No facility for that, except in my xf86aiptek device driver for X, which DOES have a bidirectional communications channel, which could have a "Unwind driver" API call a) Right now, the only thing that knows my API is my user-friendly front-end. It's not something you'd run as a daemon... b) But a subset of it certainly could. Question is, what does it listen for? Hotplug messages forwarded off of dbus? Does it monitor Hal? Is it really something that's fired off directly by hotplug? Or owned by hotplug? 5) Does udev fit into this conversation anywhere? It can be hotplug, dbus, or hal-aware, or do it's thing by itself... Since I don't know, but plan to read up on the this stuff, I just wanted to ask your opinions up-front. Certainly, there's a question as to whether hotplug wants to require the successful installation of hal, dbus. Or for that matter, adjuncts like discover, kudzu... It's a two-pronged question: what to do now, and what directions to plan for the community to move towards. -- ____ .:. ____ Bryan W. Headley - bwheadley@earthlink.net ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel