* Re: How to coordinate a DVD burn program with udev ?
From: Thomas Schmitt @ 2011-09-12 10:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
Hi,
me:
> > Is there a better place than this mailing list where i could ask for
> > advise ?
Tom Gundersen wrote:
> you could file a bug report with your distro
Anybody here who knows where to get the attention of the Debian people
who would be in charge ?
(I already have a Debian bug open for problems with U3 memory sticks
which confuse the system by pretending to be a USB hub with CD-ROM and
memory stick. Might well be udev related. No reply. Possibly filed
towards the wrong package.)
Have a nice day :)
Thomas
^ permalink raw reply
* Re: How to coordinate a DVD burn program with udev ?
From: Tom Gundersen @ 2011-09-12 9:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
On Mon, Sep 12, 2011 at 11:12 AM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> Tom Gundersen wrote:
>> Could you possibly use one of the /dev/disk/by-* links instead? As far
>> as I understand, the rule generator is being deprecated.
>
> Aside from the general problem, i can of course advise my users to use
> whatever is reliably existent and can be unambigously documented.
> The files in /dev/disk/by-id seem not to represent any of the two DVD drives.
Oh, that's odd. I have "by-id/ata-HL-DT-ST_DVDRAM_GSA-H66N_K6578SE0620
-> ../../sr0" on my system. Don't know why that would not exist.
> In /dev/disk/by-path i see them as
> /dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0
> /dev/disk/by-path/pci-0000:00:14.1-scsi-0:0:0:0
> But i understand that these addresses are prone to change at boot time, too.
The rules you posted in your first mail create the symlinks based on
these paths, so they should be exactly as reliable as your symlinks.
> And they would uglify any program message that contains a drive address.
Even if you use these things internally, you could use something else
for display. Have a look at "% udevadm info --query=all -n
/dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0" to see the available
information you could get from udev.
> Alternatively one can find the desired /dev/sr address by running
> xorriso -devices
> I could even implement in libburn a functionality similar to udev
> which identifies drives by unique persistent properties.
>
> But that would not prevent other problems which can arise from
> udev trying to inspect the busy CD drive.
I guess this is a bug in the rule generators, that should be fixed
there. I think several distro's have stopped shipping these things
though, so there might not be much interest in working on them. That
said, to the best of my knowledge Debian are still supporting them, so
there is still hope :-)
> Is there a better place than this mailing list where i could ask for advise ?
You could try on irc in #udev, or you could file a bug report with
your distro (there is no udev bugtracker).
-t
^ permalink raw reply
* Re: How to coordinate a DVD burn program with udev ?
From: Thomas Schmitt @ 2011-09-12 9:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
Hi,
Tom Gundersen wrote:
> Could you possibly use one of the /dev/disk/by-* links instead? As far
> as I understand, the rule generator is being deprecated.
Aside from the general problem, i can of course advise my users to use
whatever is reliably existent and can be unambigously documented.
The files in /dev/disk/by-id seem not to represent any of the two DVD drives.
In /dev/disk/by-path i see them as
/dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0
/dev/disk/by-path/pci-0000:00:14.1-scsi-0:0:0:0
But i understand that these addresses are prone to change at boot time, too.
And they would uglify any program message that contains a drive address.
Alternatively one can find the desired /dev/sr address by running
xorriso -devices
I could even implement in libburn a functionality similar to udev
which identifies drives by unique persistent properties.
But that would not prevent other problems which can arise from
udev trying to inspect the busy CD drive.
> Sorry to not answer your main question, I'm not sure exactly what is
> happening... Maybe someone else can shed some light on it?
The vanishing links are only one example symptom of the general problem
that udev tries to perform SCSI commands on a CD drive that is already
aquired with open(O_EXCL) and might be brought into a state which does
not tolerate such interference.
Especially with media types CD-R, CD-RW and DVD-R this often results in
misburns.
Obviously there are race conditions deciding over success or failure
of the coexistence of udev and burn program.
xorriso is hit more than the others, because it inspects the media
content additionally to the drive's MMC properties.
Nevertheless i can reproduce the problem with wodim.
It is a general one.
libburn and xorriso are part of a project that tries to improve the
neighborhood relations between Linux and burn programs.
Different to growisofs and wodim it is under maintenance (by me),
and different to the author of cdrecord i am willing to follow
instructions from the Linux developers.
But first i need to get such instructions when Linux changes its behavior.
The random permutation of /dev/sr addresses at boot time is such a change.
I understand the recommended way to cope with this device juggling
is to use the udev links.
Now what shall a user think of udev and/or xorriso if this recommended
solution goes up in smoke on first use ?
Is there a better place than this mailing list where i could ask for advise ?
Especially i wonder what the designers of kernel and udev have planned
for the use case of CD/DVD/BD burning.
Have a nice day :)
Thomas
^ permalink raw reply
* Re: How to coordinate a DVD burn program with udev ?
From: Tom Gundersen @ 2011-09-12 7:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
On Sat, Sep 10, 2011 at 12:34 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> i am developer of libburn and CD/DVD/BD burn program xorriso.
> It seems urgent that i coordinate the activities of libburn with the
> activities of udev.
>
> What is the recommended way for a library resp. a console program
> to tell udev, that the drive and the media will undergo arbitrary
> changes and should not be accessed during that time ?
>
> The particular problem case:
>
> On an installation of Debian GNU/Linux 6.0.2 amd64, /dev/dvdrw vanishes
> if libburn loads the tray. It comes back only if some other program run
> uses the /dev/sr device file to which the link should point.
>
> The effect is not always reproducible. Typically it happens with DVD+RW
> media, not with CD-RW or empty tray. It seems related to the habit
> of xorriso to inspect the media for existing ISO 9660 filesystems.
> If the system is in the mood for it, then it already happens with
> xorriso -outdev /dev/sr0
> Less frequently i can reproduce it with wodim
> wodim dev=/dev/sr0 -toc
> Quite reliably it happens with a xorriso burn run on DVD+RW (e.g. /usr/bin
> to DVD+RW):
> xorriso -outdev /dev/sr0 -blank as_needed -add /usr/bin --
>
>
> There are two drives attached to the system:
> a SATA DVD burner SH-S223B
> a PATA DVD-ROM SH-D162C
> Mostly the burner is sr0, but on some days it is sr1. So udev's links
> are needed to configure persistent addresses in backup programs.
Could you possibly use one of the /dev/disk/by-* links instead? As far
as I understand, the rule generator is being deprecated.
Sorry to not answer your main question, I'm not sure exactly what is
happening... Maybe someone else can shed some light on it?
Cheers,
Tom
^ permalink raw reply
* Re: questions about udev...beginner
From: Tom Gundersen @ 2011-09-12 7:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, Sep 12, 2011 at 9:07 AM, linuxcbon <linuxcbon@yahoo.fr> wrote:
> I am not familiar with udev and didn't find a good enough howto.
> So I ask you questions, thank you for your kind help in advance.
This is how we do it in Arch:
<http://projects.archlinux.org/initscripts.git/tree/functions#n311>.
> I have put this in rc.sysinit :
> /sbin/udevd --daemon
> /sbin/udevadm trigger
You probably want
/sbin/udevadm trigger --actiond --type=subsystems
/sbin/udevadm trigger --actiond --typeÞvices
instead (the default is only --typeÞvices, and not --type=subsystems).
> /sbin/modoprobe many modules....
> /sbin/udevadm settle
> is it the correct way of doing this ?
Looks good except for the missing subsystems bit.
> Another question is :
> Do I need rules in /etc/udev  ? Or not needed , automagical ?
You should not need any rules in /etc/udev, the standard ones shipped
in /lib/udev should be sufficient.
Cheers,
Tom
^ permalink raw reply
* questions about udev...beginner
From: linuxcbon @ 2011-09-12 7:07 UTC (permalink / raw)
To: linux-hotplug
Hi,
I am not familiar with udev and didn't find a good enough howto.
So I ask you questions, thank you for your kind help in advance.
I have put this in rc.sysinit :
/sbin/udevd --daemon
/sbin/udevadm trigger
/sbin/modoprobe many modules....
/sbin/udevadm settle
is it the correct way of doing this ?
Another question is :
Do I need rules in /etc/udev ? Or not needed , automagical ?
Best regards
^ permalink raw reply
* How to coordinate a DVD burn program with udev ?
From: Thomas Schmitt @ 2011-09-10 10:34 UTC (permalink / raw)
To: linux-hotplug
Hi,
i am developer of libburn and CD/DVD/BD burn program xorriso.
It seems urgent that i coordinate the activities of libburn with the
activities of udev.
What is the recommended way for a library resp. a console program
to tell udev, that the drive and the media will undergo arbitrary
changes and should not be accessed during that time ?
The particular problem case:
On an installation of Debian GNU/Linux 6.0.2 amd64, /dev/dvdrw vanishes
if libburn loads the tray. It comes back only if some other program run
uses the /dev/sr device file to which the link should point.
The effect is not always reproducible. Typically it happens with DVD+RW
media, not with CD-RW or empty tray. It seems related to the habit
of xorriso to inspect the media for existing ISO 9660 filesystems.
If the system is in the mood for it, then it already happens with
xorriso -outdev /dev/sr0
Less frequently i can reproduce it with wodim
wodim dev=/dev/sr0 -toc
Quite reliably it happens with a xorriso burn run on DVD+RW (e.g. /usr/bin
to DVD+RW):
xorriso -outdev /dev/sr0 -blank as_needed -add /usr/bin --
There are two drives attached to the system:
a SATA DVD burner SH-S223B
a PATA DVD-ROM SH-D162C
Mostly the burner is sr0, but on some days it is sr1. So udev's links
are needed to configure persistent addresses in backup programs.
-----------------------------------------------------------------------------
/etc/udev/rules.d/70-persistent-cd.rules
-----------------------------------------------------------------------------
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# CDDVDW_SH-S223B (pci-0000:00:11.0-scsi-2:0:0:0)
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"
# DVD-ROM_SH-D162C (pci-0000:00:14.1-scsi-0:0:0:0)
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
-----------------------------------------------------------------------------
After booting, i executed
udevadm control --log-priorityfibug
Then i put a DVD+RW into the tray, leave it open and execute:
xorriso -outdev /dev/sr0
xorriso loads the tray by SCSI command START/STOP UNIT. A few seconds
later /dev/dvdrw is gone.
The vanishing link is accompanied by these messages in /var/log/daemon.log :
------------------------------------------------------------------
Sep 9 22:00:41 debian2 udevd[435]: seq 1274 queued, 'change' 'scsi'
[...]
Sep 9 22:00:41 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep 9 22:00:41 debian2 cdrom_id[21698]: custom logging function 0x7f17909c9010 registered
Sep 9 22:00:47 debian2 cdrom_id[21698]: unable to open '/dev/sr0'
Sep 9 22:00:47 debian2 udevd-work[21697]: '/lib/udev/cdrom_id' (stderr) 'unable to open '/dev/sr0''
Sep 9 22:00:47 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' returned with exitcode 1
[...]
Sep 9 22:00:48 debian2 udevd-work[21697]: update old name, '/dev/dvdrw' no longer belonging to '/devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0'
Sep 9 22:00:48 debian2 udevd-work[21697]: no reference left, remove '/dev/dvdrw'
[... no attempt to create a new /dev/dvdrw ...]
Sep 9 22:00:48 debian2 udevd[435]: seq 1275 done with 0
------------------------------------------------------------------
It looks as if xorriso's activities block the drive while udev is trying
to get access to it in the time between 22:00:41 and 22:00:47.
The subsequent repair happens by accessing the drive again with another
xorriso -outdev /dev/sr0
This time the tray is closed.
------------------------------------------------------------------
Sep 9 22:01:06 debian2 udevd[435]: seq 1276 queued, 'change' 'scsi'
[...]
Sep 9 22:01:06 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep 9 22:01:06 debian2 cdrom_id[22669]: custom logging function 0x7f3e72142010 registered
Sep 9 22:01:10 debian2 cdrom_id[22669]: probing: '/dev/sr0'
Sep 9 22:01:10 debian2 cdrom_id[22669]: INQUIRY: [TSSTcorp][CDDVDW SH-S223B ][SB02]
[... many other SCSI inquiry command results ...]
Sep 9 22:01:16 debian2 udevd-work[21697]: LINK 'dvdrw' /etc/udev/rules.d/70-persistent-cd.rules:11
[...]
Sep 9 22:01:16 debian2 udevd-work[21697]: creating link '/dev/dvdrw' to '/dev/sr0'
Sep 9 22:01:16 debian2 udevd-work[21697]: creating symlink '/dev/dvdrw' to 'sr0'
[...]
Sep 9 22:01:16 debian2 udevd[435]: seq 1277 done with 0
------------------------------------------------------------------
wodim seems a bit less problematic, because it does not perform READ
commands. xorriso does this to learn about possible ISO 9660 fileystems.
I assume they add a few extra seconds to the drive occupation.
I tried to load the tray by
ioctl(fd, CDROMCLOSETRAY, 0);
before performing SCSI command START/STOP UNIT. No improvement seen.
Have a nice day :)
Thomas
--
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-discover roadmap
From: José Félix Ontañón @ 2011-09-03 11:07 UTC (permalink / raw)
To: linux-hotplug
Hi linux-hotplug folks!
Due to the fact that i'm going to talk about a GUI app using udev, I
don't know if this is a matter concerning the objectives of this
mailing list. Otherise I would be glad if you can point me where to
discuss about it.
Udev-discover[1][2] aims to be helping tool for udev testers, coders,
hackers and consumers. Because it provides some features beside
browsing devices via udev, I think this is not just a browser.
* Reports udev device info and udev properties
* Subsystem chooser dialog, for chosing which subsystems to deal with
* Filter devices based on string search
* Monitorize udev device events on a log window
The roadmap for the tool has been published[3] and I would like to ask
for your observations regarding some objectives defined there:
* udev-discover for educational purposes on udev
* smart filtering of devices and how could it be useful
* how can udev-discover help editing udev rules
I'm just a gui-developer but people here really has the knowledge to
judge if there's something interesting on the roadmap for helping
people who deals with udev.
Every critics or observations are welcome.
Kind regards,
[1] http://fontanon.org/udevdiscover
[2] https://launchpad.net/udev-discover
[3] http://fontanon.org/udevdiscover/roadmap/
--
http://fontanon.org
^ permalink raw reply
* Re: Input devices issue with kernel 2.6.37
From: Yegor Yefremov @ 2011-08-29 8:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAGm1_ksNiLcBSrKfcuiFfQYoAT6heC3zPeXb04hmTsudO4CBEg@mail.gmail.com>
On Mon, Aug 15, 2011 at 2:49 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> I have an ARM based SoC (TI am3517). At the time it has 3 input
> devices: touchscreen (i2c), mouse and keyboard (USB). If I start
> Debian 6.0 with 2.6.32 kernel I get all three devices listed under
> /dev/input/by-path so that I can use all of them in X::
>
> platform-i2c_omap.2-event -> ../event0
> platform-musb_hdrc-usb-0:1.3.3:1.0-event-kbd -> ../event1
> platform-musb_hdrc-usb-0:1.3.4:1.0-event-mouse -> ../event2
>
> If I take kernel 2.6.37 with the same Debian image I get only
> touchscreen listed. It looks like if
> /lib/udev/rules.d/60-persistent-input.rules would not apply during
> /dev population. But if I execute:
>
> udevadm test --actiond /sys/class/input/event1
> udevadm test --actiond /sys/class/input/event2
>
> I get all devices properly registered, so that after restarting xdm I
> can use all input devices.
>
> The same problem I have with Buildroot und udev 173.
>
> Any idea what could be wrong and why devices would not get registered
> automatically at startup with 2.6.37?
Any update on this issue? How can I debug this?
Yegor
^ permalink raw reply
* Re: [PATCH] keymap: add Genius SlimStar 320 (addon)
From: Martin Pitt @ 2011-08-29 7:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1314098491-26342-1-git-send-email-kir@openvz.org>
Hello Kir,
Kir Kolyshkin [2011-08-23 15:21 +0400]:
> This is an addition to commit 1484205c47cf3, which forgot to add
> a newly added keymap file to Makefile.am. Fix it.
Whoops, I forgot that when pushing your original commit. Applied,
thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: setting udev rules by program
From: Michael Katzmann @ 2011-08-28 20:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMyt5OSXxV+ivHdFS3BDPwW9qLHQx7CF6SAhpaC7ZSR57H_CHw@mail.gmail.com>
This is close but doesn't quite work ... If I do this it seems that
the drive mounts and then unmounts shortly after. If I use the rule...
SUBSYSTEMS="scsi",DRIVERS="sd",ENV{UDISKS_PRESENTATION_HIDE}="1"
it never mounts which is the desired behavior.
On Sun, Aug 28, 2011 at 4:11 PM, David Zeuthen <zeuthen@gmail.com> wrote:
> Hi,
>
> On Sun, Aug 28, 2011 at 2:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Udev rules or udisks act system wide, but the policy to mount a device
>> runs in the user session. The user session only talks to the
>> privileged processes which, after privilege checks, act on behalf of
>> the user.
>>
>> What you probably want, and what might be nice to have for other
>> things too, is a way for an application to dynamically inhibit the
>> user session's auto-mounting.
>>
>> And unlike the writing-out of a static file, such a dynamic lock
>> should automatically be cleared when the application goes away.
>
> This already exists, it's the --inhibit option for the udisks(1) program, see
>
> http://hal.freedesktop.org/docs/udisks/udisks.1.html
>
> or the Inhibit() method if you want to do it via D-Bus
>
> http://hal.freedesktop.org/docs/udisks/UDisks.html#UDisks.Inhibit
>
> David
>
^ permalink raw reply
* Re: setting udev rules by program
From: David Zeuthen @ 2011-08-28 20:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMyt5OSXxV+ivHdFS3BDPwW9qLHQx7CF6SAhpaC7ZSR57H_CHw@mail.gmail.com>
Hi,
On Sun, Aug 28, 2011 at 2:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Udev rules or udisks act system wide, but the policy to mount a device
> runs in the user session. The user session only talks to the
> privileged processes which, after privilege checks, act on behalf of
> the user.
>
> What you probably want, and what might be nice to have for other
> things too, is a way for an application to dynamically inhibit the
> user session's auto-mounting.
>
> And unlike the writing-out of a static file, such a dynamic lock
> should automatically be cleared when the application goes away.
This already exists, it's the --inhibit option for the udisks(1) program, see
http://hal.freedesktop.org/docs/udisks/udisks.1.html
or the Inhibit() method if you want to do it via D-Bus
http://hal.freedesktop.org/docs/udisks/UDisks.html#UDisks.Inhibit
David
^ permalink raw reply
* Re: setting udev rules by program
From: Kay Sievers @ 2011-08-28 18:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMyt5OSXxV+ivHdFS3BDPwW9qLHQx7CF6SAhpaC7ZSR57H_CHw@mail.gmail.com>
On Sun, Aug 28, 2011 at 20:19, Michael Katzmann <vk2bea@gmail.com> wrote:
> I have seen examples of udev rules using UDISKS_PRESENTATION_HIDE to prevent
> the auto-mounting of USB disks as they are attached.
>
> Rather than setting up a permanent rule, I would like to have a *program* do
> this on startup and remove the rule when it exits. How can I do this ?
You could place a rule in /run/udev/rules.d/ that does that. But see below.
> Do I need to manipulate the udev database and if so are there guidelines to
> do this ? I have seen references to sending messages on the dbus to
> org.freedesktop.UDisks but have found no documentation or examples.
>
> Can anyone give me some guidance on this ? I realize I could manipulate a
> /etc/udev/rules.d file and force the reload udev rules with "udevadm
> control" but that is really ugly... there must be a cleaner more direct
> way!
Udev rules or udisks act system wide, but the policy to mount a device
runs in the user session. The user session only talks to the
privileged processes which, after privilege checks, act on behalf of
the user.
What you probably want, and what might be nice to have for other
things too, is a way for an application to dynamically inhibit the
user session's auto-mounting.
And unlike the writing-out of a static file, such a dynamic lock
should automatically be cleared when the application goes away.
Changing system-wide behaviour is something we should avoid doing from
user applications, unless they are supposed to change the system, like
an update process or whatever.
Add David to Cc:.
Kay
^ permalink raw reply
* setting udev rules by program
From: Michael Katzmann @ 2011-08-28 18:19 UTC (permalink / raw)
To: linux-hotplug
I have seen examples of udev rules using UDISKS_PRESENTATION_HIDE to prevent
the auto-mounting of USB disks as they are attached.
Rather than setting up a permanent rule, I would like to have a *program* do
this on startup and remove the rule when it exits. How can I do this ?
Do I need to manipulate the udev database and if so are there guidelines to
do this ? I have seen references to sending messages on the dbus to
org.freedesktop.UDisks but have found no documentation or examples.
Can anyone give me some guidance on this ? I realize I could manipulate a
/etc/udev/rules.d file and force the reload udev rules with "udevadm
control" but that is really ugly... there must be a cleaner more direct
way!
thanks,
Michael
^ permalink raw reply
* Re: Writing a rule specific to a USB connector
From: Diego Iastrubni @ 2011-08-23 11:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 2:01 PM, Tom Gundersen <teg@jklm.no> wrote:
> Ok, so that explains why you don't get your 11111 symlink, the
> idVendor you are matching against is not on the device you want, but
> on a parent.
>
> I honestly don't know the best way to match against two different
> parents, which is apparently what you need. I guess something like
> this should work though:
>
> SUBSYSTEM!="hidraw", GOTO="hidraw_end"
> ATTRS{idVendor}!="c1ca", GOTO="hidraw_end"
> ATTRS{serial}="musb_hdrc", SYMLINK+="444444"
> LABEL="hidraw_end"
... and for some reason the code above did not work. However, this
ugly piece of code does. No idea what in wrong.
SUBSYSTEMS = "hidraw" , GOTO = "blabla_1"
GOTO = "blabla_end"
LABEL = "blabla_1"
ATTRS{idVendor} = "c1ca" , GOTO = "blabla_2"
GOTO = "blabla_end"
LABEL = "blabla_2"
ATTRS{serial} = "musb_hdrc" , SYMLINK += "blabla-upper"
ATTRS{serial} = "ehci-omap.0" , SYMLINK += "blabla-lower"
LABEL = "blabla_end"
^ permalink raw reply
* Re: [PATCH] [v2] keymap: add Genius SlimStar 320
From: Kir Kolyshkin @ 2011-08-23 11:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1314098226-26010-1-git-send-email-kir@openvz.org>
Please pardon the noise and ignore this one (use the 'addon' instead,
sent separately).
On 08/23/2011 03:17 PM, Kir Kolyshkin wrote:
> This keyboard have 16 "multimedia" keys plus a "4-way turbo scroll pad" which
> is essentially a round up/down/left/right button. Unfortunately most of
> these keys emit non-standard scancodes in a range 495-508 which does not
> make any sense. I tried to remap those to the best of my knowledge.
>
> Note the keyboard comes up as two event devices, second one is multimedia
> keys, so I ended up adding ENV{ID_USB_INTERFACE_NUM}="01" to avoid
> unnecessary initialization of the "main" keyboard.
>
> [v2: add a new keymap file to Makefile.am]
>
> Signed-off-by: Kir Kolyshkin<kir@openvz.org>
> ---
> Makefile.am | 1 +
> extras/keymap/95-keymap.rules | 1 +
> extras/keymap/keymaps/genius-slimstar-320 | 35 +++++++++++++++++++++++++++++
> 3 files changed, 37 insertions(+), 0 deletions(-)
> create mode 100644 extras/keymap/keymaps/genius-slimstar-320
>
> diff --git a/Makefile.am b/Makefile.am
> index 5347569..da9574c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -496,6 +496,7 @@ dist_udevkeymap_DATA = \
> extras/keymap/keymaps/fujitsu-amilo_si_1520 \
> extras/keymap/keymaps/fujitsu-esprimo_mobile_v5 \
> extras/keymap/keymaps/fujitsu-esprimo_mobile_v6 \
> + extras/keymap/keymaps/genius-slimstar-320 \
> extras/keymap/keymaps/hewlett-packard \
> extras/keymap/keymaps/hewlett-packard-2510p_2530p \
> extras/keymap/keymaps/hewlett-packard-compaq_elitebook \
> diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
> index 0d9b771..0742787 100644
> --- a/extras/keymap/95-keymap.rules
> +++ b/extras/keymap/95-keymap.rules
> @@ -20,6 +20,7 @@ GOTO="keyboard_modulecheck"
>
> LABEL="keyboard_usbcheck"
>
> +ENV{ID_VENDOR}="Genius", ENV{ID_MODEL_ID}="0708", ENV{ID_USB_INTERFACE_NUM}="01", RUN+="keymap $name genius-slimstar-320"
> ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Multimedia Keyboard", RUN+="keymap $name logitech-wave"
> ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Receiver", RUN+="keymap $name logitech-wave-cordless"
> # Logitech Cordless Wave Pro looks slightly weird; some hotkeys are coming through the mouse interface
> diff --git a/extras/keymap/keymaps/genius-slimstar-320 b/extras/keymap/keymaps/genius-slimstar-320
> new file mode 100644
> index 0000000..d0a3656
> --- /dev/null
> +++ b/extras/keymap/keymaps/genius-slimstar-320
> @@ -0,0 +1,35 @@
> +# Genius SlimStar 320
> +#
> +# Only buttons which are not properly mapped yet are configured below
> +
> +# "Scroll wheel", a circular up/down/left/right button. Aimed for scolling,
> +# but since there are no scrollleft/scrollright, let's map to back/forward.
> +0x900f0 scrollup
> +0x900f1 scrolldown
> +0x900f3 back
> +0x900f2 forward
> +
> +# Multimedia buttons, left side (from left to right)
> +# [W]
> +0x900f5 wordprocessor
> +# [Ex]
> +0x900f6 spreadsheet
> +# [P]
> +0x900f4 presentation
> +# Other five (calculator, playpause, stop, mute and eject) are OK
> +
> +# Right side, from left to right
> +# [e]
> +0xc0223 www
> +# "man"
> +0x900f7 chat
> +# "Y"
> +0x900fb prog1
> +# [X]
> +0x900f8 close
> +# "picture"
> +0x900f9 graphicseditor
> +# "two windows"
> +0x900fd scale
> +# "lock"
> +0x900fc screenlock
^ permalink raw reply
* [PATCH] keymap: add Genius SlimStar 320 (addon)
From: Kir Kolyshkin @ 2011-08-23 11:21 UTC (permalink / raw)
To: linux-hotplug
This is an addition to commit 1484205c47cf3, which forgot to add
a newly added keymap file to Makefile.am. Fix it.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
---
Makefile.am | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 5347569..da9574c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -496,6 +496,7 @@ dist_udevkeymap_DATA = \
extras/keymap/keymaps/fujitsu-amilo_si_1520 \
extras/keymap/keymaps/fujitsu-esprimo_mobile_v5 \
extras/keymap/keymaps/fujitsu-esprimo_mobile_v6 \
+ extras/keymap/keymaps/genius-slimstar-320 \
extras/keymap/keymaps/hewlett-packard \
extras/keymap/keymaps/hewlett-packard-2510p_2530p \
extras/keymap/keymaps/hewlett-packard-compaq_elitebook \
--
1.7.4.4
^ permalink raw reply related
* [PATCH] [v2] keymap: add Genius SlimStar 320
From: Kir Kolyshkin @ 2011-08-23 11:17 UTC (permalink / raw)
To: linux-hotplug
This keyboard have 16 "multimedia" keys plus a "4-way turbo scroll pad" which
is essentially a round up/down/left/right button. Unfortunately most of
these keys emit non-standard scancodes in a range 495-508 which does not
make any sense. I tried to remap those to the best of my knowledge.
Note the keyboard comes up as two event devices, second one is multimedia
keys, so I ended up adding ENV{ID_USB_INTERFACE_NUM}="01" to avoid
unnecessary initialization of the "main" keyboard.
[v2: add a new keymap file to Makefile.am]
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
---
Makefile.am | 1 +
| 1 +
| 35 +++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 extras/keymap/keymaps/genius-slimstar-320
diff --git a/Makefile.am b/Makefile.am
index 5347569..da9574c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -496,6 +496,7 @@ dist_udevkeymap_DATA = \
extras/keymap/keymaps/fujitsu-amilo_si_1520 \
extras/keymap/keymaps/fujitsu-esprimo_mobile_v5 \
extras/keymap/keymaps/fujitsu-esprimo_mobile_v6 \
+ extras/keymap/keymaps/genius-slimstar-320 \
extras/keymap/keymaps/hewlett-packard \
extras/keymap/keymaps/hewlett-packard-2510p_2530p \
extras/keymap/keymaps/hewlett-packard-compaq_elitebook \
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 0d9b771..0742787 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -20,6 +20,7 @@ GOTO="keyboard_modulecheck"
LABEL="keyboard_usbcheck"
+ENV{ID_VENDOR}="Genius", ENV{ID_MODEL_ID}="0708", ENV{ID_USB_INTERFACE_NUM}="01", RUN+="keymap $name genius-slimstar-320"
ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Multimedia Keyboard", RUN+="keymap $name logitech-wave"
ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Receiver", RUN+="keymap $name logitech-wave-cordless"
# Logitech Cordless Wave Pro looks slightly weird; some hotkeys are coming through the mouse interface
--git a/extras/keymap/keymaps/genius-slimstar-320 b/extras/keymap/keymaps/genius-slimstar-320
new file mode 100644
index 0000000..d0a3656
--- /dev/null
+++ b/extras/keymap/keymaps/genius-slimstar-320
@@ -0,0 +1,35 @@
+# Genius SlimStar 320
+#
+# Only buttons which are not properly mapped yet are configured below
+
+# "Scroll wheel", a circular up/down/left/right button. Aimed for scolling,
+# but since there are no scrollleft/scrollright, let's map to back/forward.
+0x900f0 scrollup
+0x900f1 scrolldown
+0x900f3 back
+0x900f2 forward
+
+# Multimedia buttons, left side (from left to right)
+# [W]
+0x900f5 wordprocessor
+# [Ex]
+0x900f6 spreadsheet
+# [P]
+0x900f4 presentation
+# Other five (calculator, playpause, stop, mute and eject) are OK
+
+# Right side, from left to right
+# [e]
+0xc0223 www
+# "man"
+0x900f7 chat
+# "Y"
+0x900fb prog1
+# [X]
+0x900f8 close
+# "picture"
+0x900f9 graphicseditor
+# "two windows"
+0x900fd scale
+# "lock"
+0x900fc screenlock
--
1.7.4.4
^ permalink raw reply related
* Re: Writing a rule specific to a USB connector
From: Tom Gundersen @ 2011-08-23 11:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 12:45 PM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 12:51 PM, Tom Gundersen <teg@jklm.no> wrote:
>> I guess c1ca is not the idVendor of your hidraw device, but of one of
>> it its parents. Could you post the output of "udevadm info --query=all
>> --name=/dev/hidraw0 --attribute-walk" (without the egrep)?
>
> [/root 10.10.10.44] $ udevadm info --query=all --name=/dev/hidraw0
> --attribute-walk
[...]
> looking at device
> '/devices/platform/musb_hdrc/usb1/1-1/1-1.1/1-1.1:1.0/0003:C1CA:0003.0001/hidraw/hidraw0':
> KERNEL="hidraw0"
> SUBSYSTEM="hidraw"
> DRIVER=""
[...]
> looking at parent device '/devices/platform/musb_hdrc/usb1/1-1/1-1.1':
> KERNELS="1-1.1"
> SUBSYSTEMS="usb"
> DRIVERS="usb"
> ATTRS{configuration}="Default configuration"
> ATTRS{bNumInterfaces}=" 1"
> ATTRS{bConfigurationValue}="1"
> ATTRS{bmAttributes}="40"
> ATTRS{bMaxPower}=" 0mA"
> ATTRS{urbnum}="41"
> ATTRS{idVendor}="c1ca"
> ATTRS{idProduct}="0003"
> ATTRS{bcdDevice}="0000"
> ATTRS{bDeviceClass}="00"
> ATTRS{bDeviceSubClass}="00"
> ATTRS{bDeviceProtocol}="00"
> ATTRS{bNumConfigurations}="1"
> ATTRS{bMaxPacketSize0}="8"
> ATTRS{speed}="12"
> ATTRS{busnum}="1"
> ATTRS{devnum}="3"
> ATTRS{devpath}="1.1"
> ATTRS{version}=" 1.01"
> ATTRS{maxchild}="0"
> ATTRS{quirks}="0x0"
> ATTRS{authorized}="1"
> ATTRS{manufacturer}="Sysmop tech."
> ATTRS{product}="USB PALM"
[...]
> looking at parent device '/devices/platform/musb_hdrc/usb1':
> KERNELS="usb1"
> SUBSYSTEMS="usb"
> DRIVERS="usb"
> ATTRS{configuration}=""
> ATTRS{bNumInterfaces}=" 1"
> ATTRS{bConfigurationValue}="1"
> ATTRS{bmAttributes}="e0"
> ATTRS{bMaxPower}=" 0mA"
> ATTRS{urbnum}="26"
> ATTRS{idVendor}="1d6b"
> ATTRS{idProduct}="0002"
> ATTRS{bcdDevice}="0206"
> ATTRS{bDeviceClass}="09"
> ATTRS{bDeviceSubClass}="00"
> ATTRS{bDeviceProtocol}="00"
> ATTRS{bNumConfigurations}="1"
> ATTRS{bMaxPacketSize0}="64"
> ATTRS{speed}="480"
> ATTRS{busnum}="1"
> ATTRS{devnum}="1"
> ATTRS{devpath}="0"
> ATTRS{version}=" 2.00"
> ATTRS{maxchild}="1"
> ATTRS{quirks}="0x0"
> ATTRS{authorized}="1"
> ATTRS{manufacturer}="Linux 2.6.32 musb-hcd"
> ATTRS{product}="MUSB HDRC host driver"
> ATTRS{serial}="musb_hdrc"
> ATTRS{authorized_default}="1"
Ok, so that explains why you don't get your 11111 symlink, the
idVendor you are matching against is not on the device you want, but
on a parent.
I honestly don't know the best way to match against two different
parents, which is apparently what you need. I guess something like
this should work though:
SUBSYSTEM!="hidraw", GOTO="hidraw_end"
ATTRS{idVendor}!="c1ca", GOTO="hidraw_end"
ATTRS{serial}="musb_hdrc", SYMLINK+="444444"
LABEL="hidraw_end"
Maybe someone else knows a better solution?
Cheers,
Tom
^ permalink raw reply
* Re: Writing a rule specific to a USB connector
From: Diego Iastrubni @ 2011-08-23 10:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 12:51 PM, Tom Gundersen <teg@jklm.no> wrote:
> I guess c1ca is not the idVendor of your hidraw device, but of one of
> it its parents. Could you post the output of "udevadm info --query=all
> --name=/dev/hidraw0 --attribute-walk" (without the egrep)?
[/root 10.10.10.44] $ udevadm info --query=all --name=/dev/hidraw0
--attribute-walk
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/platform/musb_hdrc/usb1/1-1/1-1.1/1-1.1:1.0/0003:C1CA:0003.0001/hidraw/hidraw0':
KERNEL="hidraw0"
SUBSYSTEM="hidraw"
DRIVER=""
looking at parent device
'/devices/platform/musb_hdrc/usb1/1-1/1-1.1/1-1.1:1.0/0003:C1CA:0003.0001':
KERNELS="0003:C1CA:0003.0001"
SUBSYSTEMS="hid"
DRIVERS="generic-usb"
looking at parent device
'/devices/platform/musb_hdrc/usb1/1-1/1-1.1/1-1.1:1.0':
KERNELS="1-1.1:1.0"
SUBSYSTEMS="usb"
DRIVERS="usbhid"
ATTRS{bInterfaceNumber}="00"
ATTRS{bAlternateSetting}=" 0"
ATTRS{bNumEndpoints}="01"
ATTRS{bInterfaceClass}="03"
ATTRS{bInterfaceSubClass}="00"
ATTRS{bInterfaceProtocol}="00"
ATTRS{supports_autosuspend}="1"
ATTRS{interface}="BIOGOARD"
looking at parent device '/devices/platform/musb_hdrc/usb1/1-1/1-1.1':
KERNELS="1-1.1"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}="Default configuration"
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="40"
ATTRS{bMaxPower}=" 0mA"
ATTRS{urbnum}="41"
ATTRS{idVendor}="c1ca"
ATTRS{idProduct}="0003"
ATTRS{bcdDevice}="0000"
ATTRS{bDeviceClass}="00"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="8"
ATTRS{speed}="12"
ATTRS{busnum}="1"
ATTRS{devnum}="3"
ATTRS{devpath}="1.1"
ATTRS{version}=" 1.01"
ATTRS{maxchild}="0"
ATTRS{quirks}="0x0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Sysmop tech."
ATTRS{product}="USB PALM"
looking at parent device '/devices/platform/musb_hdrc/usb1/1-1':
KERNELS="1-1"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}="100mA"
ATTRS{urbnum}="50"
ATTRS{idVendor}="05e3"
ATTRS{idProduct}="0608"
ATTRS{bcdDevice}="0702"
ATTRS{bDeviceClass}="09"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="01"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="64"
ATTRS{speed}="480"
ATTRS{busnum}="1"
ATTRS{devnum}="2"
ATTRS{devpath}="1"
ATTRS{version}=" 2.00"
ATTRS{maxchild}="4"
ATTRS{quirks}="0x0"
ATTRS{authorized}="1"
ATTRS{product}="USB2.0 Hub"
looking at parent device '/devices/platform/musb_hdrc/usb1':
KERNELS="usb1"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}=" 0mA"
ATTRS{urbnum}="26"
ATTRS{idVendor}="1d6b"
ATTRS{idProduct}="0002"
ATTRS{bcdDevice}="0206"
ATTRS{bDeviceClass}="09"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="64"
ATTRS{speed}="480"
ATTRS{busnum}="1"
ATTRS{devnum}="1"
ATTRS{devpath}="0"
ATTRS{version}=" 2.00"
ATTRS{maxchild}="1"
ATTRS{quirks}="0x0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Linux 2.6.32 musb-hcd"
ATTRS{product}="MUSB HDRC host driver"
ATTRS{serial}="musb_hdrc"
ATTRS{authorized_default}="1"
looking at parent device '/devices/platform/musb_hdrc':
KERNELS="musb_hdrc"
SUBSYSTEMS="platform"
DRIVERS="musb_hdrc"
ATTRS{mode}="a_host"
ATTRS{vbus}="Vbus off, timeout 1100"
looking at parent device '/devices/platform':
KERNELS="platform"
SUBSYSTEMS=""
DRIVERS=""
^ permalink raw reply
* Re: Writing a rule specific to a USB connector
From: Tom Gundersen @ 2011-08-23 9:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 10:59 AM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> KERNEL="hidraw[0-9]*", ATTR{idVendor}="c1ca", SYMLINK+="1111111"
[...]
> [/root 10.10.10.44] $ udevadm info --query=all --name=/dev/hidraw0
> --attribute-walk 2>&1 | egrep 'serial|idVendor'
> ATTRS{idVendor}="c1ca"
> ATTRS{idVendor}="05e3"
> ATTRS{idVendor}="1d6b"
> ATTRS{serial}="musb_hdrc"
>
> I was expecting to see "11111", and I don't. This explains why
> "444444" is not working. Still - something is not working here.
I guess c1ca is not the idVendor of your hidraw device, but of one of
it its parents. Could you post the output of "udevadm info --query=all
--name=/dev/hidraw0 --attribute-walk" (without the egrep)?
-t
^ permalink raw reply
* Re: Writing a rule specific to a USB connector
From: Diego Iastrubni @ 2011-08-23 8:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 11:15 AM, Tom Gundersen <teg@jklm.no> wrote:
> ATTRS matches on a parent device, two instances of ATTRS matches on
> _the same_ parent device. In your case I guess idVendor and serial
> match on different parent devices, which would explain why they work
> separately but no together.
Eventually I found a documentation that mentions this, but in was not
easy. A very stable difference, hard to understand (now documented in
this archive!). Thanks!
> Sounds to me like you should have used:
>
> KERNEL="hidraw[0-9]*", ATTR{idVendor}="c1ca",
> ATTRS{serial}="musb_hdrc", SYMLINK+="eeeeeeeee"
KERNEL="hidraw[0-9]*", ATTR{idVendor}="c1ca", SYMLINK+="1111111"
KERNEL="hidraw[0-9]*", ATTRS{idVendor}="c1ca", SYMLINK+="2222222"
KERNEL="hidraw[0-9]*", ATTRS{serial}="musb_hdrc", SYMLINK+="3333333"
KERNEL="hidraw[0-9]*", ATTR{idVendor}="c1ca",
ATTRS{serial}="musb_hdrc", SYMLINK+="4444444"
[/root 10.10.10.44] $ udevadm test /sys/class/hidraw/hidraw0 2>&1 | grep DEV
UDEV_LOG=6
DEVPATH=/devices/platform/musb_hdrc/usb1/1-1/1-1.1/1-1.1:1.0/0003:C1CA:0003.0008/hidraw/hidraw0
DEVNAME=/dev/hidraw0
DEVLINKS=/dev/2222222 /dev/3333333
[/root 10.10.10.44] $ udevadm info --query=all --name=/dev/hidraw0
--attribute-walk 2>&1 | egrep 'serial|idVendor'
ATTRS{idVendor}="c1ca"
ATTRS{idVendor}="05e3"
ATTRS{idVendor}="1d6b"
ATTRS{serial}="musb_hdrc"
I was expecting to see "11111", and I don't. This explains why
"444444" is not working. Still - something is not working here.
^ permalink raw reply
* Re: Writing a rule specific to a USB connector
From: Tom Gundersen @ 2011-08-23 8:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEKoBhLMJOONv_5d9TwEGEk6oJD1M8iBvenFdJCy16SOuQ@mail.gmail.com>
On Tue, Aug 23, 2011 at 10:03 AM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> KERNEL="hidraw[0-9]*", ATTRS{serial}="musb_hdrc", SYMLINK+="aaaaaaaaaa"
> KERNEL="hidraw[0-9]*", ATTRS{idVendor}="c1ca", SYMLINK+="bbbbbbbbbbb"
>
>
> OK, works. I see both links generated. Now I need to combine them:
>
> KERNEL="hidraw[0-9]*", ATTRS{idVendor}="c1ca",
> ATTRS{serial}="musb_hdrc", SYMLINK+="cccccccccc"
> KERNEL="hidraw[0-9]*", ATTRS{serial}="musb_hdrc",
> ATTRS{idVendor}="c1ca", SYMLINK+="dddddddddd"
ATTRS matches on a parent device, two instances of ATTRS matches on
_the same_ parent device. In your case I guess idVendor and serial
match on different parent devices, which would explain why they work
separately but no together.
Finally you say:
> None working. What I think in happening is that the idVendor of the
> USB hub is matched and not of the device. I need to match:
>
> ATTR{idVendor}="c1ca" and some parent has ATTRS{serial}="musb_hdrc"
>
>
> What is the golden rule I am missing?
Sounds to me like you should have used:
KERNEL="hidraw[0-9]*", ATTR{idVendor}="c1ca",
ATTRS{serial}="musb_hdrc", SYMLINK+="eeeeeeeee"
Cheers,
Tom
^ permalink raw reply
* Writing a rule specific to a USB connector
From: Diego Iastrubni @ 2011-08-23 8:03 UTC (permalink / raw)
To: linux-hotplug
Hi all,
Sorry if this offtopic is this list, in such case please point me to
correct location.
I am tring to write a rule that will create a specific char device for
every different USB connector (this is an embeeded application, and
the use case is: "please connect the device to the upper connector").
I am using 173 on 2.6.32/arm.
I have two different USB controllers which can be identified by
ATTRS{serial}="musb_hdrc" and ATTRS{serial}="ehci-omap.0"
First try:
KERNEL="hidraw[0-9]*", ATTRS{serial}="musb_hdrc", SYMLINK+="aaaaaaaaaa"
KERNEL="hidraw[0-9]*", ATTRS{idVendor}="c1ca", SYMLINK+="bbbbbbbbbbb"
OK, works. I see both links generated. Now I need to combine them:
KERNEL="hidraw[0-9]*", ATTRS{idVendor}="c1ca",
ATTRS{serial}="musb_hdrc", SYMLINK+="cccccccccc"
KERNEL="hidraw[0-9]*", ATTRS{serial}="musb_hdrc",
ATTRS{idVendor}="c1ca", SYMLINK+="dddddddddd"
None working. What I think in happening is that the idVendor of the
USB hub is matched and not of the device. I need to match:
ATTR{idVendor}="c1ca" and some parent has ATTRS{serial}="musb_hdrc"
What is the golden rule I am missing?
- diego
^ permalink raw reply
* [PATCH] keymap: add Genius SlimStar 320
From: Kir Kolyshkin @ 2011-08-19 14:21 UTC (permalink / raw)
To: linux-hotplug
This keyboard have 16 "multimedia" keys plus a "4-way turbo scroll pad" which
is essentially a round up/down/left/right button. Unfortunately most of
these keys emit non-standard scancodes in a range 495-508 which does not
make any sense. I tried to remap those to the best of my knowledge.
Note the keyboard comes up as two event devices, second one is multimedia
keys, so I ended up adding ENV{ID_USB_INTERFACE_NUM}="01" to avoid
unnecessary initialization of the "main" keyboard.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
---
| 1 +
| 35 +++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 extras/keymap/keymaps/genius-slimstar-320
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 0d9b771..0742787 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -20,6 +20,7 @@ GOTO="keyboard_modulecheck"
LABEL="keyboard_usbcheck"
+ENV{ID_VENDOR}="Genius", ENV{ID_MODEL_ID}="0708", ENV{ID_USB_INTERFACE_NUM}="01", RUN+="keymap $name genius-slimstar-320"
ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Multimedia Keyboard", RUN+="keymap $name logitech-wave"
ENV{ID_VENDOR}="Logitech*", ATTRS{name}="Logitech USB Receiver", RUN+="keymap $name logitech-wave-cordless"
# Logitech Cordless Wave Pro looks slightly weird; some hotkeys are coming through the mouse interface
--git a/extras/keymap/keymaps/genius-slimstar-320 b/extras/keymap/keymaps/genius-slimstar-320
new file mode 100644
index 0000000..d0a3656
--- /dev/null
+++ b/extras/keymap/keymaps/genius-slimstar-320
@@ -0,0 +1,35 @@
+# Genius SlimStar 320
+#
+# Only buttons which are not properly mapped yet are configured below
+
+# "Scroll wheel", a circular up/down/left/right button. Aimed for scolling,
+# but since there are no scrollleft/scrollright, let's map to back/forward.
+0x900f0 scrollup
+0x900f1 scrolldown
+0x900f3 back
+0x900f2 forward
+
+# Multimedia buttons, left side (from left to right)
+# [W]
+0x900f5 wordprocessor
+# [Ex]
+0x900f6 spreadsheet
+# [P]
+0x900f4 presentation
+# Other five (calculator, playpause, stop, mute and eject) are OK
+
+# Right side, from left to right
+# [e]
+0xc0223 www
+# "man"
+0x900f7 chat
+# "Y"
+0x900fb prog1
+# [X]
+0x900f8 close
+# "picture"
+0x900f9 graphicseditor
+# "two windows"
+0x900fd scale
+# "lock"
+0x900fc screenlock
--
1.7.4.4
^ permalink raw reply related
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