From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Date: Sun, 27 Feb 2005 00:27:55 +0000 Subject: Re: event sequencing Message-Id: <9e47339105022616271cb0676c@mail.gmail.com> 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, 26 Feb 2005 20:41:16 +0100, Kay Sievers wrote: > >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. I'm still thinking about this one. But you could use a parallel argument on disks, and eliminate the MOUNT event. Maybe MOUNT should be replaced with a child too. > 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. This part I definitely agree with. -- Jon Smirl jonsmirl@gmail.com ------------------------------------------------------- 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