public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Holger Macht <hmacht@suse.de>
To: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	linux-acpi@vger.kernel.org
Subject: Re: Docking support?
Date: Sat, 9 Jun 2007 18:38:14 +0200	[thread overview]
Message-ID: <20070609163814.GA21202@homac> (raw)
In-Reply-To: <20070608090403.c712d79e.kristen.c.accardi@intel.com>

On Fri 08. Jun - 09:04:03, Kristen Carlson Accardi wrote:
> On Fri, 7 Nov 2036 16:00:45 +0100
> Holger Macht <hmacht@suse.de> wrote:
> 
> > On Fri 08. Jun - 18:47:06, Samuel Thibault wrote:
> > [...]
> > > Also, I'd really like to receive ACPI docking events in userland for
> > > triggering video devices configuration for instance.
> > 
> > Via udev. Unfortunately....
> > 
> > I just tries and it doesn't work properly.
> > 
> > Dock driver contains something like this:
> > 
> > ---
> >        /*
> >         * here we need to generate the undock
> >         * event prior to actually doing the undock
> >         * so that the device struct still exists.
> >         */
> >         dock_event(ds, event, UNDOCK_EVENT);
> >         hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST);
> >         undock(ds);
> >         eject_dock(ds);
> > ---
> > 
> > When udev receives the KOBJ_CHANGE event triggered by dock_event(), some
> > application or udev itself does read the content of
> > /sys/devices/platform/dock.0/docked. But the value is not updated
> > yet. Checking manually with cat, it sometimes even needs up to two seconds
> > for the right value (0) to show up. So we cannot rely on getting the real
> > state at the point in time where the udev event is received.
> > 
> > At first, function dock_event(..) doesn't need any of the passed
> > arguments. It only makes use of the static platform_device dock_device
> > object to execute a kobject_uevent(). So wouldn't it be save to execute
> > the dock_event() _after_ actually undocking? Something like the following?
> 
> Actually it does - the latest patches sent to Len contain modifications
> to pass an ENV value with the dock event so that userspace can use that
> to determine whether we are doing or undocking.   You might check out
> the "immediate_undock" module parameter patch that I also sent to Len that
> will allow you to write scripts to do work before the undock actually
> happens - http://marc.info/?l=linux-kernel&m=117874881923973&w=2

Oh yes, I saw the immediate_undock patch, but the one with the uevent
changes somehow slipped through my attention. Thanks.

 - Holger

  reply	other threads:[~2007-06-09 16:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 10:47 Docking support? Samuel Thibault
2007-06-08 13:00 ` Holger Macht
2007-06-08 16:04   ` Kristen Carlson Accardi
2007-06-09 16:38     ` Holger Macht [this message]
2007-06-08 16:07 ` Kristen Carlson Accardi
2007-06-11  9:42   ` Samuel Thibault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070609163814.GA21202@homac \
    --to=hmacht@suse.de \
    --cc=kristen.c.accardi@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=samuel.thibault@ens-lyon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox