From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 26 Feb 2005 19:41:16 +0000 Subject: Re: event sequencing Message-Id: <1109446876.7400.112.camel@localhost.localdomain> List-Id: References: <9e473391050225081838f673c7@mail.gmail.com> In-Reply-To: <9e473391050225081838f673c7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sat, 2005-02-26 at 14:17 -0500, Jon Smirl wrote: >On Sat, 26 Feb 2005 19:28:10 +0100, Kay Sievers wrote: >> Are the list and the current state available as device attributes in >> sysfs? So you may just send a KOBJ_CHANGE event for that specific >> attributes with the kobject_uevent() which can have an attribute passed >> down which is appended to the devpath of the device. > >Mode and modes are both sysfs variables so KOBJ_CHANGE should work to >send the events to hal. These are the public events that everyone >should know about. That sounds good, yes. >That leaves my private monitor change interrupt event in >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't >make sense to remove/add the framebuffer device just because the >monitor attached changed. Remove/add would force X to close the >framebuffer device and lose all of the state loaded inside of it (font >cache, textures if DRM is running) . For exactly that reason I was asking if it wouldn't be better to create a child for the monitor, which can appear and disappear and can hold the DDC data you get from the physical monitor. >What about adding a few defines for KOBJ_HELPER_1, KOBJ_HELPER_2, >KOBJ_HELPER_3, etc? Wouldn't this be better than making specific >defines for private helpers like my DDC decoder? KOBJ_HELPER would be >context specific on the class of the device. Hmm, I'm not sure here. Can't you add the device specific stuff to the environment and send out KOBJ_REQUEST_DATA or something? (See below.) >I also want to modify request_firmware() to be more general. Secondary >video cards need to be posted before the sysfs class is created. >request_firmware() almost does what I need. It would be more useful if >I renamed it to request_initialization() then created two events: >KOBJ_FIRMWARE and KOBJ_POST. Alternatively I could pass FIRMWARE or >POST as an environment variable. The user space post program is the >same for all video cards. I think the request_firmware() should be redesigned in a generic request_user_data(kobj) call. This event would copy arbitrary data into a sysfs file and something like KOBJ_REQUEST_DATA would do it. The call should create a file inside of a existing device and the event handler should copy the data into this file instead of creating a own class device for the firmware as we do today. Kay ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&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