public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
To: Holger Macht <hmacht@suse.de>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	linux-acpi@vger.kernel.org
Subject: Re: Docking support?
Date: Fri, 8 Jun 2007 09:04:03 -0700	[thread overview]
Message-ID: <20070608090403.c712d79e.kristen.c.accardi@intel.com> (raw)
In-Reply-To: <20361107150045.GA25276@homac.suse.de>

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

Kristen

  reply	other threads:[~2007-06-08 16:07 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 [this message]
2007-06-09 16:38     ` Holger Macht
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=20070608090403.c712d79e.kristen.c.accardi@intel.com \
    --to=kristen.c.accardi@intel.com \
    --cc=hmacht@suse.de \
    --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