* Re: udev and acer batteries
From: Stéphane Guedon @ 2010-08-12 17:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: Text/Plain, Size: 8070 bytes --]
Le Thursday 12 August 2010 07:25:56, Martin Pitt a écrit :
> Hello Stéphane,
>
> Stéphane Guedon [2010-08-11 19:08 +0200]:
> > I am writing to you concerning acer batteries.
> > My laptop batteries aren't detected until I plug in/out the ac_adaptator.
> > If I am at home, working on it, no problem. But if I am out of buildings,
> > where I can't have power, my power status won't be detected by my desktop
> > environnement.
>
> This is most probably a bug in hal. KDE still uses hal for hardware
> detection/management, but since it's unmaintained, I wouldn't expect
> this to be fixed anytime soon or at all.
>
> Out of interest, can you install "upower" on your machine (if it's not
> already present), and in this situation (i. e. boot when on battery
> without AC), check the output of "upower --dump" whether it detects
> your battery?
>
> Thanks,
>
> Martin
with ac power on, but battery not yet recognize :
19:44:52 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:45:09 2010 (0 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
after plugging out and in :
19:45:09 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:47:07 2010 (6 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1
vendor: SANYO
model: AS07B31
serial: 30996
power supply: yes
updated: Thu Aug 12 19:47:12 2010 (1 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 48.3294 Wh
energy-empty: 0 Wh
energy-full: 48.3294 Wh
energy-full-design: 48.84 Wh
energy-rate: 5.6499 W
voltage: 12.594 V
percentage: 100%
capacity: 98.9545%
technology: lithium-ion
History (charge):
1281635230 100.000 fully-charged
1281635226 99.426 fully-charged
1281635222 99.495 fully-charged
1281635222 0.000 unknown
History (rate):
1281635232 5.650 fully-charged
1281635224 30.225 fully-charged
1281635222 3.419 fully-charged
1281635222 0.000 unknown
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
reboot on battery :
19:53:49 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:53:52 2010 (0 seconds ago)
has history: no
has statistics: no
line-power
online: no
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
plugging in the ac adatator
19:53:52 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:54:02 2010 (2 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1
vendor: SANYO
model: AS07B31
serial: 30996
power supply: yes
updated: Thu Aug 12 19:54:04 2010 (0 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: charging
energy: 46.62 Wh
energy-empty: 0 Wh
energy-full: 48.3294 Wh
energy-full-design: 48.84 Wh
energy-rate: 37.2738 W
voltage: 11.929 V
time to full: 2.8 minutes
percentage: 96.463%
capacity: 98.9545%
technology: lithium-ion
History (charge):
1281635643 96.463 charging
1281635643 0.000 unknown
History (rate):
1281635643 37.274 charging
1281635643 0.000 unknown
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
Hope this will help you, and me !
Thanks
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Add keymap for Lenovo IdeaPad S10-3
From: David Woodhouse @ 2010-08-12 16:04 UTC (permalink / raw)
To: linux-hotplug
Tested on S10-3, but presumably applicable to all IdeaPads.
---
| 2 ++
| 7 +++++++
2 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 extras/keymap/keymaps/lenovo-ideapad
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 13b5571..2241422 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -65,6 +65,8 @@ ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="*3000*", RUN+="keymap $name lenovo-3000"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X6*", ATTR{[dmi/id]product_version}="* Tablet" RUN+="keymap $name lenovo-thinkpad_x6_tablet"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X200 Tablet*", ATTR{[dmi/id]product_version}="* Tablet" RUN+="keymap $name lenovo-thinkpad_x200_tablet"
+ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="*IdeaPad*", RUN+="keymap $name lenovo-ideapad"
+ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_name}="S10-*", RUN+="keymap $name lenovo-ideapad"
ENV{DMI_VENDOR}="Hewlett-Packard*", RUN+="keymap $name hewlett-packard"
ENV{DMI_VENDOR}="Hewlett-Packard*", ATTR{[dmi/id]product_name}="*[tT][aA][bB][lL][eE][tT]*", RUN+="keymap $name hewlett-packard-tablet"
--git a/extras/keymap/keymaps/lenovo-ideapad b/extras/keymap/keymaps/lenovo-ideapad
new file mode 100644
index 0000000..9f241fb
--- /dev/null
+++ b/extras/keymap/keymaps/lenovo-ideapad
@@ -0,0 +1,7 @@
+# Key codes observed on S10-3, assumed valid on other IdeaPad models
+0xB9 brightnessup # does nothing in BIOS
+0xBA brightnessdown # does nothing in BIOS
+0xF1 camera # BIOS toggles camera power
+0x83 display_off # BIOS toggles screen state
+0x81 rfkill # does nothing in BIOS
+0xf2 unknown # trackpad enable/disable (does nothing in BIOS)
--
1.7.2.1
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
* Re: udev and acer batteries
From: Martin Pitt @ 2010-08-12 5:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Hello Stéphane,
Stéphane Guedon [2010-08-11 19:08 +0200]:
> I am writing to you concerning acer batteries.
> My laptop batteries aren't detected until I plug in/out the ac_adaptator.
> If I am at home, working on it, no problem. But if I am out of buildings,
> where I can't have power, my power status won't be detected by my desktop
> environnement.
This is most probably a bug in hal. KDE still uses hal for hardware
detection/management, but since it's unmaintained, I wouldn't expect
this to be fixed anytime soon or at all.
Out of interest, can you install "upower" on your machine (if it's not
already present), and in this situation (i. e. boot when on battery
without AC), check the output of "upower --dump" whether it detects
your battery?
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Kay Sievers @ 2010-08-11 19:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
On Wed, Aug 11, 2010 at 19:08, Stéphane Guedon <stephane@22decembre.eu> wrote:
> I am writing to you concerning acer batteries.
> My laptop batteries aren't detected until I plug in/out the ac_adaptator.
> If I am at home, working on it, no problem. But if I am out of buildings,
> where I can't have power, my power status won't be detected by my desktop
> environnement.
>
> In fact, sysfs detect it at boot and display it's state. But kde seems to look
> at udev event :
> -when I switch off udev service, and plug in or out my adaptator, kde detect
> nothing !
> - if I start again udev (just after stopping it and plug in/out adaptator),
> kde detect it !
Udev does not do anything with batteries. It just receives events
about them from the kernel.
There are no rules or setup at udev's side which should change things,
it's all inside the kernel.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* udev and acer batteries
From: Stéphane Guedon @ 2010-08-11 17:08 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: Text/Plain, Size: 2626 bytes --]
Hello
I am writing to you concerning acer batteries.
My laptop batteries aren't detected until I plug in/out the ac_adaptator.
If I am at home, working on it, no problem. But if I am out of buildings,
where I can't have power, my power status won't be detected by my desktop
environnement.
In fact, sysfs detect it at boot and display it's state. But kde seems to look
at udev event :
-when I switch off udev service, and plug in or out my adaptator, kde detect
nothing !
- if I start again udev (just after stopping it and plug in/out adaptator),
kde detect it !
When I look at events in boot, I can see that my battery is detect by udev :
Aug 11 18:45:24 luciole hald[5494]: 18:45:24.981 [I] coldplug.c:221: found
(udevdb export)
'/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD' ->
'/dev/(null)'
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [I] coldplug.c:94: creating
HotplugEvent for
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [I] coldplug.c:285: new event
(dev node from udev)
'/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD' ''
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [I] coldplug.c:319: new event
(no dev node)
'/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD'
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [D] hotplug.c:476: checking
ADD event /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [D] hotplug.c:397: event
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD: skip
ourselves and all later events
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [I] hotplug.c:145:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD is a device
(subsystem)
Aug 11 18:45:25 luciole hald[5494]: 18:45:25.445 [I] device.c:5002: add_dev:
subsys=power_supply
sysfs_path=/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
dev= parent_dev=0x00000000
In same time, I have found rules for toshiba laptop for example, but not for
acer laptop.
As far as I understand, my battery is detected when power status change while
udev is running.
So I would like to know if a rule for acer is being writed, if you need
informations I can give you...
Tank you for you help.
Best regards
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [ANNOUNCE] udev 161 release
From: Kay Sievers @ 2010-08-11 16:00 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 161
====
Bugfixes.
^ permalink raw reply
* Re: Behavior with duplicate UUID's
From: Kay Sievers @ 2010-08-11 8:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1008082106310.18424@bear.techie.net>
On Wed, Aug 11, 2010 at 05:05, Scott Talbert <talbert@techie.net> wrote:
> On Mon, 9 Aug 2010, Kay Sievers wrote:
>
>> The behavior is undefined, and can only be controlled with
>> link_priority= option.
>>
>> We can't, and don't want to pretend to make any control over 'the
>> first one'. In a hotplug world, there is almost never a correct first
>> one, because everything runs in parallel.
>
> I agree with you that if two devices are hotplugged at around the same time,
> the result would be expectedly unpredictable. However, if you have your
> root partition (with a symlink established at bootup), and then hours later,
> you hotplug another device, it would seem to me that the symlink of the
> older device would be preferable to keep. Right now, the symlink for the
> original device is removed and a symlink for the new one is added.
>
> I propose a slightly different change. This changes the symlink priority
> processing when the priorities are the same. The oldest symlink is instead
> preferred, rather than the newest one.
Well, other people might want it the other way around, and want to
access the device they just plugged-in. Or they want to find the raid
device after setting it up, not the member of the raid.
Also multiple events run in parallel when a device is discovered, not
even partitions from the same device have any defined ordering here.
So, there is absolutely no guarantee about that, it's just luck in
many cases, which one wins.
As said, it does not really make sense to try to optimize anything
here, we don't have under control.
Kay
^ permalink raw reply
* Re: Behavior with duplicate UUID's
From: Scott Talbert @ 2010-08-11 3:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1008082106310.18424@bear.techie.net>
On Mon, 9 Aug 2010, Kay Sievers wrote:
> The behavior is undefined, and can only be controlled with
> link_priority= option.
>
> We can't, and don't want to pretend to make any control over 'the
> first one'. In a hotplug world, there is almost never a correct first
> one, because everything runs in parallel.
I agree with you that if two devices are hotplugged at around the same
time, the result would be expectedly unpredictable. However, if you have
your root partition (with a symlink established at bootup), and then hours
later, you hotplug another device, it would seem to me that the symlink of
the older device would be preferable to keep. Right now, the symlink for
the original device is removed and a symlink for the new one is added.
I propose a slightly different change. This changes the symlink priority
processing when the priorities are the same. The oldest symlink is
instead preferred, rather than the newest one.
--- udev-node.c.orig 2010-05-20 11:06:52.000000000 -0400
+++ udev-node.c 2010-08-10 22:52:53.000000000 -0400
@@ -261,9 +261,10 @@
devnode = udev_device_get_devnode(dev_db);
if (devnode != NULL) {
- dbg(udev, "compare priority of '%s'(%i) > '%s'(%i)\n", target, priority,
- udev_device_get_devnode(dev_db), udev_device_get_devlink_priority(dev_db));
- if (target = NULL || udev_device_get_devlink_priority(dev_db) > priority) {
+ dbg(udev, "compare priority of '%s'(%i) >= '%s'(%i)\n",
+ udev_device_get_devnode(dev_db), udev_device_get_devlink_priority(dev_db),
+ target, priority);
+ if (target = NULL || udev_device_get_devlink_priority(dev_db) >= priority) {
info(udev, "'%s' claims priority %i for '%s'\n",
udev_device_get_syspath(dev_db), udev_device_get_devlink_priority(dev_db), stackdir);
priority = udev_device_get_devlink_priority(dev_db);
---
Thanks,
Scott
^ permalink raw reply
* Re: Environment woes
From: Greg KH @ 2010-08-10 20:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C608323.5010502@draisberghof.de>
On Tue, Aug 10, 2010 at 10:02:10PM +0200, Josua Dietze wrote:
> Am 10.08.2010 21:30, schrieb Greg KH:
> >Let the modem-manager program handle knowing which tty device to use,
> >that type of logic can usually only be detected after talking to the
> >device.
>
>
> Unfortunately, I keep receiving reports that modem-manager picks the
> wrong port after probing, and there is no way of setting the port
> manually in NetworkManager. This happens mostly with devices where
> the interrupt port has a number > 0. I have yet to meet a GSM modem
> device where the "interrupt rule" does *not* apply.
Then point people at the modem-manager developers :)
> I usually recommend using wvdial (autoprobing problems too) and edit
> the port directly in the config file. And just entering "gsmmodem"
> spares users the testing of all ports, some of which may seem to
> work at first but then build up a very unreliable connection.
It sounds like this is information that the modem-manager developers
would like to know about, so that they can pick the correct ports. Or
is it networkmanager that does that these days, I can't remember, sorry.
Either way, I don't see this a function of the modeswitch program at
all.
good luck,
greg k-h
^ permalink raw reply
* Re: Environment woes
From: Josua Dietze @ 2010-08-10 20:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C608323.5010502@draisberghof.de>
Am 10.08.2010 21:30, schrieb Greg KH:
> On Tue, Aug 10, 2010 at 12:37:23AM +0200, Josua Dietze wrote:
>> I maintain a Linux tool to put USB devices from one mode (or state)
>> to the other.
>
> What program, usb-modeswitch?
That's the one, yes.
>> Usually there is more than one interface exposed after the mode
>> switch, but only one is suitable for a wireless connection; binding
>> the GSM driver ("option") or the generic serial driver will add
>> multiple ports though (ttyUSB).
>
> Let the modem-manager program handle knowing which tty device to use,
> that type of logic can usually only be detected after talking to the
> device.
Unfortunately, I keep receiving reports that modem-manager picks the
wrong port after probing, and there is no way of setting the port
manually in NetworkManager. This happens mostly with devices where the
interrupt port has a number > 0. I have yet to meet a GSM modem device
where the "interrupt rule" does *not* apply.
I usually recommend using wvdial (autoprobing problems too) and edit
the port directly in the config file. And just entering "gsmmodem"
spares users the testing of all ports, some of which may seem to work
at first but then build up a very unreliable connection.
> And what happens with your tool when in the near future, we want to talk
> to those other device nodes because modem-manager knows what thoes ports
> do and how to get the data out of them?
The usb_modeswitch helper in the post-switch rule only picks ttyUSB
ports and looks only for their transfer type. It doesn't do anything
to the ports if they are bulk.
Note that this is unrelated to the preceding switching process and
doesn't change anything at all except that one symlink.
And yes, it can be scrapped anytime without further consequences when
there are other solutions. It is a temporary workaround to make user's
life a little easier.
> In short, you shouldn't have to do any of this.
I couldn't agree more! :-)
Regards,
Josua Dietze
^ permalink raw reply
* Re: Environment woes
From: Greg KH @ 2010-08-10 19:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C608323.5010502@draisberghof.de>
On Tue, Aug 10, 2010 at 12:37:23AM +0200, Josua Dietze wrote:
> Hi everyone,
>
> I am in need of a friendly hint regarding a delicate matter ...
>
> I maintain a Linux tool to put USB devices from one mode (or state)
> to the other.
What program, usb-modeswitch?
> Usually there is more than one interface exposed after the mode
> switch, but only one is suitable for a wireless connection; binding
> the GSM driver ("option") or the generic serial driver will add
> multiple ports though (ttyUSB).
Let the modem-manager program handle knowing which tty device to use,
that type of logic can usually only be detected after talking to the
device.
And what happens with your tool when in the near future, we want to talk
to those other device nodes because modem-manager knows what thoes ports
do and how to get the data out of them?
In short, you shouldn't have to do any of this.
thanks,
greg k-h
^ permalink raw reply
* Re: Environment woes
From: Josua Dietze @ 2010-08-10 6:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C608323.5010502@draisberghof.de>
Am 10.08.2010 06:37, schrieb Kay Sievers:
> On Tue, Aug 10, 2010 at 00:37, Josua Dietze<digidietze@draisberghof.de> wrote:
>> Up to now I have used a rule to add a symlink to the "right" port; the check
>> is done by a script via "PROGRAM". If the port is not right, the result of
>> the script is empty, thus no symlink:
>>
>> ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script> %p", SYMLINK="%c"
>
> Who needs these custom links? Why don't you just use the stuff in
> /dev/serial/ which should already work?
There is a symlink to *every* port in the /dev/serial folders. Again,
only *one* of them is usable for connecting through
wvdial/umtsmon/networkmanager. The latter often auto-selects a wrong
port, BTW.
I add *one* symlink called "gsmmodem[x]" to make life easier for users.
Examples:
Huawei E160 ttyUSB0,1,2 gsmmodem -> ttyUSB0
ZTE MF110 ttyUSB0,1,2 gsmmodem -> ttyUSB2
These interfaces all have a class of 0xff. Some are even accepting AT
commands, but are only intended for diagnostic purposes, misleading
users and probers.
Thanks,
Josua Dietze
^ permalink raw reply
* Re: [PATCH] Add DDC_DEVICE to the types that are managed by udev-acl
From: Kay Sievers @ 2010-08-10 6:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinTfgHE=tOcT3ZTR2vL5f87KJDHTvNSRecG02-A@mail.gmail.com>
On Mon, Aug 9, 2010 at 12:51, Richard Hughes <hughsient@gmail.com> wrote:
> DDC_DEVICEs are useful control points for high-end monitors such as
> the HP DreamColor. The DDC/CI interface allows userspace applications
> to upload custom colorspaces and interact with the display without
> using the monitor hardware controls.
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: Environment woes
From: Kay Sievers @ 2010-08-10 4:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C608323.5010502@draisberghof.de>
On Tue, Aug 10, 2010 at 00:37, Josua Dietze <digidietze@draisberghof.de> wrote:
> Up to now I have used a rule to add a symlink to the "right" port; the check
> is done by a script via "PROGRAM". If the port is not right, the result of
> the script is empty, thus no symlink:
>
> ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script> %p", SYMLINK="%c"
Who needs these custom links? Why don't you just use the stuff in
/dev/serial/ which should already work?
Kay
^ permalink raw reply
* Environment woes
From: Josua Dietze @ 2010-08-09 22:37 UTC (permalink / raw)
To: linux-hotplug
Hi everyone,
I am in need of a friendly hint regarding a delicate matter ...
I maintain a Linux tool to put USB devices from one mode (or state) to
the other. Many wireless sticks support that "feature", showing up as
a storage device and providing their Windows drivers onboard. To be
used as modems they are switched by these drivers (once they are
installed) to their second mode.
This can be handled in Linux and is properly tested.
Usually there is more than one interface exposed after the mode
switch, but only one is suitable for a wireless connection; binding
the GSM driver ("option") or the generic serial driver will add
multiple ports though (ttyUSB).
Up to now I have used a rule to add a symlink to the "right" port; the
check is done by a script via "PROGRAM". If the port is not right, the
result of the script is empty, thus no symlink:
ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script> %p", SYMLINK="%c"
To handle *only* the device that was switched by my other rules, I
stored the bus and device number during the switching process in a
temporary file which is then used by the <script>. I had tried to work
with ENV first but failed.
You might already guess what I'm going to ask ...
I was reprimanded - and rightly so - for using the temp file, which is
said to be insecure and not working at boot time.
But I am at a loss how I should signal from one enumeration event to
annother without using a file; neither ENV nor IMPORT are working,
probably because the different modes behave like two unrelated
devices, storage and serial. Quite often the USB ID changes with the
mode switch.
Is there really no environment that can be accessed from both
scripts/events?
Or is there a third way maybe?
The order of events is guaranteed in my case ...
Thanks,
Josua Dietze
^ permalink raw reply
* [PATCH] Add DDC_DEVICE to the types that are managed by udev-acl
From: Richard Hughes @ 2010-08-09 10:51 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
DDC_DEVICEs are useful control points for high-end monitors such as
the HP DreamColor. The DDC/CI interface allows userspace applications
to upload custom colorspaces and interact with the display without
using the monitor hardware controls.
Note: the DDC/CI parts can't really be added to the kernel API, as
DDC/CI is very vendor specific. To upload a custom colorspace to a HP
monitor requires lots of per-model and per-vendor specific parsing
code, and this really doesn't want to be in the kernel. For this
reason gnome-color-manager is using i2c-dev and the attached patch to
be able to upload custom colorspaces to the monitor from userspace
without using a privalege escalation framework such as PolicyKit, with
the logic the user can already change most of the settings of ddc/ci
using xrandr. If a malicous application can already switch off the
monitor using xrandr, then the same program being able to change the
colorspace and deguass the monitor is not really your biggest worry.
Please review, and consider. Thanks.
Richard.
[-- Attachment #2: 0001-Add-DDC_DEVICE-to-the-types-that-are-managed-by-udev.patch --]
[-- Type: application/octet-stream, Size: 1207 bytes --]
From 4c09eef2b6e5182430c5014fa6237fea3a480623 Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Mon, 9 Aug 2010 11:41:18 +0100
Subject: [PATCH] Add DDC_DEVICE to the types that are managed by udev-acl
DDC_DEVICEs are control points for high-end monitors such as the
HP DreamColor. The DDC/CI interface allows userspace applications
to upload custom colorspaces and interact with the display without
using the monitor hardware controls.
---
| 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index 25e3f60..6ec04ee 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -57,6 +57,9 @@ SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl"
# color measurement devices
ENV{COLOR_MEASUREMENT_DEVICE}=="*?", TAG+="udev-acl"
+# DDC/CI device, usually high-end monitors such as the DreamColor
+ENV{DDC_DEVICE}=="*?", TAG+="udev-acl"
+
# apply ACL for all locally logged in users
LABEL="acl_apply", TAG=="udev-acl", TEST=="/var/run/ConsoleKit/database", \
RUN+="udev-acl --action=$env{ACTION} --device=$env{DEVNAME}"
--
1.7.2.1
^ permalink raw reply related
* Re: Behavior with duplicate UUID's
From: Kay Sievers @ 2010-08-09 8:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1008082106310.18424@bear.techie.net>
On Mon, Aug 9, 2010 at 03:19, Scott Talbert <talbert@techie.net> wrote:
> I am looking at udev's behavior when duplicate UUID's are present (ie,
> partition a and partition b both have the same UUID) in a system. Yes, this
> is a rather rare case, but it can happen if, for instance, one partition is
> cloned to another.
>
> Right now, it appears that the behavior for creating the /dev/disk/by-uuid
> links is "last one in wins." For example, if I have /dev/sda1 with UUID X
> in a system, and then add another drive with a /dev/sdb1 with UUID X,
> /dev/sdb1 ends up with its link in /dev/disk/by-uuid. It would seem to me
> that "first one in wins" might be a better approach. That is, when
> /dev/sdb1 comes along later, /dev/sda1's link would persist in
> /dev/disk/by-uuid.
The behavior is undefined, and can only be controlled with
link_priority= option.
We can't, and don't want to pretend to make any control over 'the
first one'. In a hotplug world, there is almost never a correct first
one, because everything runs in parallel.
Kay
^ permalink raw reply
* Behavior with duplicate UUID's
From: Scott Talbert @ 2010-08-09 1:19 UTC (permalink / raw)
To: linux-hotplug
Hello,
I am looking at udev's behavior when duplicate UUID's are present (ie,
partition a and partition b both have the same UUID) in a system. Yes,
this is a rather rare case, but it can happen if, for instance, one
partition is cloned to another.
Right now, it appears that the behavior for creating the /dev/disk/by-uuid
links is "last one in wins." For example, if I have /dev/sda1 with UUID X
in a system, and then add another drive with a /dev/sdb1 with UUID X,
/dev/sdb1 ends up with its link in /dev/disk/by-uuid. It would seem to me
that "first one in wins" might be a better approach. That is, when
/dev/sdb1 comes along later, /dev/sda1's link would persist in
/dev/disk/by-uuid.
Thoughts? I modified the existing rule slightly (see below) and this
seems to implement the "first one in" behavior.
--- /lib/udev/rules.d/60-persistent-storage.rules 2010-04-19 05:30:29.000000000 -0400
+++ parted/60-persistent-storage.rules 2010-08-08 20:43:45.000000000 -0400
@@ -63,7 +63,7 @@
KERNEL!="sr*", OPTIONS+="watch"
# by-label/by-uuid links (filesystem metadata)
-ENV{ID_FS_USAGE}="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
+ENV{ID_FS_USAGE}="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}="?*", TEST!="/dev/disk/by-uuid/$env{ID_FS_UUID_ENC}",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}" ENV{ID_FS_USAGE}="filesystem|other", ENV{ID_FS_LABEL_ENC}="?*",
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"
# by-id (World Wide Name)
--
Thanks,
Scott Talbert
^ permalink raw reply
* Re: [PATCH 3/3] udev: remove the compile warning
From: Martin Pitt @ 2010-08-08 18:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100806072831.GP29131@kai-debian>
Hello Yin,
Yin Kangkai [2010-08-06 15:28 +0800]:
> udev: remove the compile warning
Thanks! Applied.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH 2/3] udevd: try to create the links only when the
From: Martin Pitt @ 2010-08-08 18:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100806072609.GO29131@kai-debian>
Hello Yin,
Yin Kangkai [2010-08-06 15:26 +0800]:
> udevd: try to create the links only when the target exists
Thanks! Applied with some typo fixes and a clarified description.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH 1/3] udevd: unref udev device in error path
From: Martin Pitt @ 2010-08-08 18:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100806072358.GN29131@kai-debian>
Hello Yin,
Yin Kangkai [2010-08-06 15:23 +0800]:
> udevd: unref udev device in error path
Ah, nice catch! Applied.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH 3/3] udev: remove the compile warning
From: Yin Kangkai @ 2010-08-06 7:28 UTC (permalink / raw)
To: linux-hotplug
From 9d9167e76771e2310ce073ebee14cf0919860ac1 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Fri, 6 Aug 2010 15:08:51 +0800
Subject: [PATCH 3/3] udev: remove the compile warning
CC udev/udevd.o
In file included from udev/udev.h:27,
from udev/udevd.c:47:
./libudev/libudev-private.h: In function ‘udev_selinux_setfscreateconat’:
./libudev/libudev-private.h:230: warning: declaration of ‘dirfd’ shadows a global declaration
/usr/include/dirent.h:224: warning: shadowed declaration is here
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
libudev/libudev-private.h | 4 ++--
libudev/libudev-selinux-private.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libudev/libudev-private.h b/libudev/libudev-private.h
index fa408f6..475f992 100644
--- a/libudev/libudev-private.h
+++ b/libudev/libudev-private.h
@@ -227,14 +227,14 @@ static inline void udev_selinux_init(struct udev *udev) {}
static inline void udev_selinux_exit(struct udev *udev) {}
static inline void udev_selinux_lsetfilecon(struct udev *udev, const char *file, unsigned int mode) {}
static inline void udev_selinux_setfscreatecon(struct udev *udev, const char *file, unsigned int mode) {}
-static inline void udev_selinux_setfscreateconat(struct udev *udev, int dirfd, const char *file, unsigned int mode) {}
+static inline void udev_selinux_setfscreateconat(struct udev *udev, int dfd, const char *file, unsigned int mode) {}
static inline void udev_selinux_resetfscreatecon(struct udev *udev) {}
#else
void udev_selinux_init(struct udev *udev);
void udev_selinux_exit(struct udev *udev);
void udev_selinux_lsetfilecon(struct udev *udev, const char *file, unsigned int mode);
void udev_selinux_setfscreatecon(struct udev *udev, const char *file, unsigned int mode);
-void udev_selinux_setfscreateconat(struct udev *udev, int dirfd, const char *file, unsigned int mode);
+void udev_selinux_setfscreateconat(struct udev *udev, int dfd, const char *file, unsigned int mode);
void udev_selinux_resetfscreatecon(struct udev *udev);
#endif
diff --git a/libudev/libudev-selinux-private.c b/libudev/libudev-selinux-private.c
index 2d4463d..be68aa1 100644
--- a/libudev/libudev-selinux-private.c
+++ b/libudev/libudev-selinux-private.c
@@ -83,7 +83,7 @@ void udev_selinux_resetfscreatecon(struct udev *udev)
err(udev, "setfscreatecon failed: %m\n");
}
-void udev_selinux_setfscreateconat(struct udev *udev, int dirfd, const char *file, unsigned int mode)
+void udev_selinux_setfscreateconat(struct udev *udev, int dfd, const char *file, unsigned int mode)
{
char filename[UTIL_PATH_SIZE];
--
1.6.5
^ permalink raw reply related
* [PATCH 2/3] udevd: try to create the links only when the target
From: Yin Kangkai @ 2010-08-06 7:26 UTC (permalink / raw)
To: linux-hotplug
From 966aab6e1035e607f7c7f4329393bf68c39d49da Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Thu, 5 Aug 2010 16:17:00 +0800
Subject: [PATCH 2/3] udevd: try to create the links only when the target exists
For example, not all the systems have the PROC_KCORE enalbed but a broken
symbol link be created in spite of that.
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevd.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index 6dc9795..61b76f5 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -900,10 +900,14 @@ static void static_dev_create_links(struct udev *udev, DIR *dir)
unsigned int i;
for (i = 0; i < ARRAY_SIZE(stdlinks); i++) {
- udev_selinux_setfscreateconat(udev, dirfd(dir), stdlinks[i].link, S_IFLNK);
- if (symlinkat(stdlinks[i].target, dirfd(dir), stdlinks[i].link) < 0 && errno = EEXIST)
- utimensat(dirfd(dir), stdlinks[i].link, NULL, AT_SYMLINK_NOFOLLOW);
- udev_selinux_resetfscreatecon(udev);
+ struct stat sb;
+
+ if (stat(stdlinks[i].target, &sb) = 0) {
+ udev_selinux_setfscreateconat(udev, dirfd(dir), stdlinks[i].link, S_IFLNK);
+ if (symlinkat(stdlinks[i].target, dirfd(dir), stdlinks[i].link) < 0 && errno = EEXIST)
+ utimensat(dirfd(dir), stdlinks[i].link, NULL, AT_SYMLINK_NOFOLLOW);
+ udev_selinux_resetfscreatecon(udev);
+ }
}
}
--
1.6.5
^ permalink raw reply related
* [PATCH 1/3] udevd: unref udev device in error path
From: Yin Kangkai @ 2010-08-06 7:23 UTC (permalink / raw)
To: linux-hotplug
From 09610e30e2b2c087393afe1d620e5e6d75271503 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Thu, 5 Aug 2010 11:47:48 +0800
Subject: [PATCH 1/3] udevd: unref udev device in error path
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevd.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index 2808117..6dc9795 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -402,13 +402,13 @@ static void event_run(struct event *event, bool force)
worker_new(event);
}
-static void event_queue_insert(struct udev_device *dev)
+static int event_queue_insert(struct udev_device *dev)
{
struct event *event;
event = calloc(1, sizeof(struct event));
if (event = NULL)
- return;
+ return -1;
event->udev = udev_device_get_udev(dev);
event->dev = dev;
@@ -429,8 +429,10 @@ static void event_queue_insert(struct udev_device *dev)
/* run all events with a timeout set immediately */
if (udev_device_get_timeout(dev) > 0) {
event_run(event, true);
- return;
+ return 0;
}
+
+ return 0;
}
static void worker_kill(struct udev *udev, int retain)
@@ -1351,9 +1353,8 @@ int main(int argc, char *argv[])
dev = udev_monitor_receive_device(monitor);
if (dev != NULL)
- event_queue_insert(dev);
- else
- udev_device_unref(dev);
+ if (event_queue_insert(dev) < 0)
+ udev_device_unref(dev);
}
/* start new events */
--
1.6.5
^ permalink raw reply related
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 22:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 09:20, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Aug 5, 2010 at 21:05, Philip Tait <philip@naoj.org> wrote:
>> Is it safe to update Udev to a newer version that has this capability
>> (say 146), (I have to keep the same kernel version), or is it better
>> to try to update the rules to implement this feature with version 125?
>
> It's entirely distro specific what will happen if you replace the
> stock version, nobody will really be able to tell for sure what would
> happen, I guess.
>
> Maybe the rules can be backported to the old version. Here is the change:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¼4c751802147f1ff21bf52a57a2976754949453
Yes, they did back-port successfully! Problem solved - many thanks.
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox