* [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
* Re: [PATCH][RFC] rules: add persistent vf mac rules generator for
From: Marco d'Itri @ 2011-08-18 22:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313663068-26397-1-git-send-email-lidongyang@novell.com>
On Aug 18, Kay Sievers <kay.sievers@vrfy.org> wrote:
> We are about to kill the entire rule_generator in the next months. It
> has too man problems, and does not really solve any real world
> problem:
> The majority of systems does not rely on predictable names, and does
> not need any automatic rules mangling from the hotplug path.
For the records: the Debian community so far has not found any reason to
retire the rules generators, since they solve problems experienced by
our users base and do not cause significant troubles.
I plan to keep maintaining this code as long as it will be needed, and I
welcome coordination with other interested vendors.
> This all is expected to happen during the next months, and the code to
> do this will likely be merged into systemd and not udev. The udev rule
This probably rules it out as a solution for Debian: there are serious
doubts that systemd will be ever adopted since it is actively hostile to
supporting the toy ports.
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH][RFC] rules: add persistent vf mac rules generator for
From: Kay Sievers @ 2011-08-18 11:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313663068-26397-1-git-send-email-lidongyang@novell.com>
On Thu, Aug 18, 2011 at 12:24, Li Dongyang <lidongyang@novell.com> wrote:
> This is the rule generator for SR-IOV device intel 82576,
> because the mac address of each Virtual Function interfaces are generated
> randomly each time the igb driver loaded, this is a way to make the
> mac of the VFs consistent cross reboots.
> What we do is when we see the VFs up first time, we record each mac
> and generate a rule, writing each mac into the rule and set it via ip utility
> on the next boot.
>
> and when we generate the rule, we block and wait on the files under /sys
> cause sometimes the udev event is triggerd before the VFs are up completely,
> and we might see no mac of the VFs if we do not block. However, during
> installation of a system like SLES, the rule generator will stall
> and wait for the file, so I think some suggestions are needed, Thanks
We are about to kill the entire rule_generator in the next months. It
has too man problems, and does not really solve any real world
problem:
The majority of systems does not rely on predictable names, and does
not need any automatic rules mangling from the hotplug path.
The systems who rely on predictable names need manual configuration
anyway. So we will just require explicit configuration for predictable
names instead of automatically generating system config from the
hotplug path.
The rule_generator cause too many problems to continue it. The
intersection of systems who need it and the systems which do not have
manual config anyway is almost zero, so it makes not much sense to
continue that road.
The current plan is to have a generic format for network configuration
and create udev rules and systemd service files on-the-fly at bootup,
before udev is even started. The generated udev rules will trigger
when devices show up in the hotplug path and rename the interfaces.
Systemd will start a service for the every configured interface which
will apply the needed IP config or start things like the dhcp client.
Unconfigured interfaces without a specific matching configuration file
will just keep the kernel's name, there will be no try to create any
persistent records for it.
This all is expected to happen during the next months, and the code to
do this will likely be merged into systemd and not udev. The udev rule
generator will be deleted in the longer run. We tried, but we need to
admit today, that it isn't the solution we are looking for, to solve
issues regarding predictable network interface names.
Thanks,
Kay
^ permalink raw reply
* [PATCH][RFC] rules: add persistent vf mac rules generator for SR-IOV device intel 82576
From: Li Dongyang @ 2011-08-18 10:24 UTC (permalink / raw)
To: linux-hotplug
This is the rule generator for SR-IOV device intel 82576,
because the mac address of each Virtual Function interfaces are generated
randomly each time the igb driver loaded, this is a way to make the
mac of the VFs consistent cross reboots.
What we do is when we see the VFs up first time, we record each mac
and generate a rule, writing each mac into the rule and set it via ip utility
on the next boot.
and when we generate the rule, we block and wait on the files under /sys
cause sometimes the udev event is triggerd before the VFs are up completely,
and we might see no mac of the VFs if we do not block. However, during
installation of a system like SLES, the rule generator will stall
and wait for the file, so I think some suggestions are needed, Thanks
Signed-off-by: Li Dongyang <lidongyang@novell.com>
---
Makefile.am | 10 ++-
.../75-persistent-mac-vf-generator.rules | 1 +
| 13 +++
| 35 +++++++++
| 81 ++++++++++++++++++++
5 files changed, 137 insertions(+), 3 deletions(-)
create mode 100644 extras/rule_generator/75-persistent-mac-vf-generator.rules
create mode 100644 extras/rule_generator/set_vf_mac
create mode 100644 extras/rule_generator/vf_mac.functions
create mode 100644 extras/rule_generator/write_vf_mac_rules
diff --git a/Makefile.am b/Makefile.am
index 5347569..3f868ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -579,14 +579,18 @@ if ENABLE_RULE_GENERATOR
# ------------------------------------------------------------------------------
dist_libexec_SCRIPTS += \
extras/rule_generator/write_cd_rules \
- extras/rule_generator/write_net_rules
+ extras/rule_generator/write_net_rules \
+ extras/rule_generator/write_vf_mac_rules \
+ extras/rule_generator/set_vf_mac
udevhomedir = $(libexecdir)
-dist_udevhome_DATA = extras/rule_generator/rule_generator.functions
+dist_udevhome_DATA = extras/rule_generator/rule_generator.functions \
+ extras/rule_generator/vf_mac.functions
dist_udevrules_DATA += \
extras/rule_generator/75-cd-aliases-generator.rules \
- extras/rule_generator/75-persistent-net-generator.rules
+ extras/rule_generator/75-persistent-net-generator.rules \
+ extras/rule_generator/75-persistent-mac-vf-generator.rules
endif
if ENABLE_UDEV_ACL
diff --git a/extras/rule_generator/75-persistent-mac-vf-generator.rules b/extras/rule_generator/75-persistent-mac-vf-generator.rules
new file mode 100644
index 0000000..d18eea9
--- /dev/null
+++ b/extras/rule_generator/75-persistent-mac-vf-generator.rules
@@ -0,0 +1 @@
+ATTR{vendor}="0x8086", ATTR{device}="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="write_vf_mac_rules"
--git a/extras/rule_generator/set_vf_mac b/extras/rule_generator/set_vf_mac
new file mode 100644
index 0000000..e539a7c
--- /dev/null
+++ b/extras/rule_generator/set_vf_mac
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+. /lib/udev/vf_mac.functions
+
+PCI_SLOT_NAME=$1
+VF_MAC=$2
+
+get_pf_name $PCI_SLOT_NAME
+get_vf_id $PCI_SLOT_NAME
+
+/sbin/ip link set dev $PF_INF_NAME vf $VF_ID mac $VF_MAC
+
+exit 0
--git a/extras/rule_generator/vf_mac.functions b/extras/rule_generator/vf_mac.functions
new file mode 100644
index 0000000..19896d7
--- /dev/null
+++ b/extras/rule_generator/vf_mac.functions
@@ -0,0 +1,35 @@
+# functions used by set_vf_mac and write_vf_mac_rules
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation version 2 of the License.
+
+get_pf_name() {
+ local pci_slot_id="$1"
+ local name
+ while [ 1 ]; do
+ if [ -d /sys/bus/pci/devices/${pci_slot_id}/physfn/net/ ]; then
+ break
+ fi
+ done
+ for name in /sys/bus/pci/devices/${pci_slot_id}/physfn/net/* ;do
+ PF_INF_NAME=${name##*/}
+ done
+}
+
+get_vf_id() {
+ local pci_slot_id="$1"
+ local name
+ while [ 1 ]; do
+ if [ -d /sys/bus/pci/devices/${pci_slot_id}/physfn/ ]; then
+ break
+ fi
+ done
+ for name in /sys/bus/pci/devices/${pci_slot_id}/physfn/virtfn* ;do
+ readlink "$name" | grep -q "$pci_slot_id"
+ if [ $? -eq 0 ] ;then
+ VF_ID=${name##${name%%?}}
+ return 0
+ fi
+ done
+}
--git a/extras/rule_generator/write_vf_mac_rules b/extras/rule_generator/write_vf_mac_rules
new file mode 100644
index 0000000..6f4a9ca
--- /dev/null
+++ b/extras/rule_generator/write_vf_mac_rules
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+# This script is run to create persistent network device naming rules
+# based on properties of the device.
+# If the interface needs to be renamed, INTERFACE_NEW=<name> will be printed
+# on stdout to allow udev to IMPORT it.
+
+# variables used to communicate:
+# PCI_SLOT_NAME The pci slot name of one virtual function inited
+
+# Copyright (C) 2011 Li Dongyang <lidongyang@novell.com>
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+
+RULES_FILE='/etc/udev/rules.d/70-persistent-mac-vf.rules'
+
+. /lib/udev/rule_generator.functions
+. /lib/udev/vf_mac.functions
+
+if [ -z "$PCI_SLOT_NAME" ]; then
+ echo "missing \$PCI_SLOT_NAME" >&2
+ exit 1
+fi
+
+if [ -e $RULES_FILE ]; then
+ grep -q $PCI_SLOT_NAME $RULES_FILE
+ if [ $? -eq 0 ]; then
+ exit 0
+ fi
+fi
+
+write_rule() {
+ local pci_slot_name="$1"
+ local vf_mac="$2"
+ local comment="$3"
+
+ {
+ if [ "$PRINT_HEADER" ]; then
+ PRINT_HEADER+ echo "# This file was automatically generated by the $0"
+ echo "# program, run by the persistent-mac-vf-generator.rules rules file."
+ echo "#"
+ echo "# You can modify it, as long as you keep each rule on a single"
+ echo "# line, and change only the value of the MAC you want."
+ fi
+
+ echo ""
+ [ "$comment" ] && echo "# $comment"
+ echo "SUBSYSTEM=\"pci\", ACTION=\"change\", KERNEL=\"$pci_slot_name\", RUN+=\"set_vf_mac $pci_slot_name $vf_mac\""
+ } >> $RULES_FILE
+}
+
+get_pf_name $PCI_SLOT_NAME
+get_vf_id $PCI_SLOT_NAME
+
+VF_MAC=$(ip link show $PF_INF_NAME | grep "vf $VF_ID")
+VF_MAC=${VF_MAC##* }
+
+# Prevent concurrent processes from modifying the file at the same time.
+lock_rules_file
+
+# Check if the rules file is writeable.
+choose_rules_file
+
+write_rule "$PCI_SLOT_NAME" "$VF_MAC"
+
+unlock_rules_file
+
+exit 0
--
1.7.6
^ permalink raw reply related
* Re: Udev support for Ultima Cutter
From: Greg KH @ 2011-08-17 13:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAPVe_eAvd_o7kQMk8aQyJjKX_S-MUn0yMewJwz=Vs62900aWHA@mail.gmail.com>
On Wed, Aug 17, 2011 at 01:40:02PM +0000, Olafur Arason wrote:
> I don't have /dev/serial/* I'm using Ubuntu 11.04 if that helps.
Please file a bug with Ubuntu to add those persistant links, that is
exactly what you want here.
greg k-h
^ permalink raw reply
* Re: Udev support for Ultima Cutter
From: Kay Sievers @ 2011-08-17 13:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAPVe_eAvd_o7kQMk8aQyJjKX_S-MUn0yMewJwz=Vs62900aWHA@mail.gmail.com>
On Wed, Aug 17, 2011 at 15:40, Olafur Arason <olafura@olafura.com> wrote:
> I don't have /dev/serial/* I'm using Ubuntu 11.04 if that helps.
/dev/serial/looks like this usually:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h¼4c751802147f1ff21bf52a57a2976754949453
> It seems to be linked to /dev/bus/usb/002/002 but a consistent path is
> needed for privileges and less frustration with always re-configuring the tools.
Which kernel driver binds to the device?
Kay
^ permalink raw reply
* Re: Udev support for Ultima Cutter
From: Olafur Arason @ 2011-08-17 13:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAPVe_eAvd_o7kQMk8aQyJjKX_S-MUn0yMewJwz=Vs62900aWHA@mail.gmail.com>
I don't have /dev/serial/* I'm using Ubuntu 11.04 if that helps.
Here is a diff of before and after plugin in my cutter:
647,671d646
< P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1
< N: bus/usb/002/002
< E: UDEV_LOG=3
< E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1
< E: MAJOR\x189
< E: MINOR\x129
< E: DEVNAME=/dev/bus/usb/002/002
< E: DEVTYPE=usb_device
< E: DRIVER=usb
< E: PRODUCTÃ0/6001/200
< E: TYPE=0/0/0
< E: BUSNUM\02
< E: DEVNUM\02
< E: SUBSYSTEM=usb
<
< P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
< E: UDEV_LOG=3
< E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
< E: DEVTYPE=usb_interface
< E: PRODUCTÃ0/6001/200
< E: TYPE=0/0/0
< E: INTERFACE%5/255/255
< E: MODALIAS=usb:v0C30p6001d0200dc00dsc00dp00icFFiscFFipFF
< E: SUBSYSTEM=usb
It seems to be linked to /dev/bus/usb/002/002 but a consistent path is
needed for privileges and less frustration with always re-configuring the tools.
Also it's important that devices like this work automatically for everybody.
Regards,
Olafur Arason
On Wed, Aug 17, 2011 at 13:27, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Aug 17, 2011 at 13:48, Olafur Arason <olafura@olafura.com> wrote:
>> Hi, I need a udev rule file for Mutoh Ultima Cutter. It would be
>> preferable if it links
>> to /dev/cutter so I know which device to link to. This is a serial usb
>> connection.
>> I have previously managed to write data to this interface and have tried to make
>> a rule file but I don't know why it does not work and the udevadm
>> monitor interface
>> does not give me any clues.
>
> Check /dev/serial/* if there is a link already that fits?
>
> Kay
>
^ permalink raw reply
* [PATCH] revised OLPC keymap
From: Paul Fox @ 2011-08-17 13:39 UTC (permalink / raw)
To: linux-hotplug
udev's OLPC keymap has been out of date for a while, but it went
unnoticed: udev's maps weren't being used until we fully retired hal.
paul
commit de157fd68f83023ab86837a8e9a9b1bdc2d12494
Author: Paul Fox <pgf@laptop.org>
Date: Mon Aug 15 16:58:38 2011 -0400
update the OLPC keymap for correct function key behavior
new mappings were needed when the mechanical keyboard was
introduced, and gnome was made a peer to the sugar desktop.
see http://lists.laptop.org/pipermail/devel/2010-July/029384.html
diff --git a/extras/keymap/keymaps/olpc-xo b/extras/keymap/keymaps/olpc-xo
index 7fe0662..34434a1 100644
--- a/extras/keymap/keymaps/olpc-xo
+++ b/extras/keymap/keymaps/olpc-xo
@@ -2,18 +2,32 @@
0x81 fn_esc
0xF9 camera
0xF8 sound # Fn-CAMERA = Mic
-0xBB fn_f1
-0xBC fn_f2
-0xBD fn_f3
-0xBE fn_f4
-0xBF fn_f5
-0xC0 fn_f6
-0xC1 fn_f7
-0xC2 fn_f8
-0xC3 fn_f9
-0xC4 fn_f10
-0xD7 fn_f11
-0xD8 fn_f12
+
+
+# Function key mappings, as per
+# http://dev.laptop.org/ticket/10213#comment:20
+#
+# Unmodified F1-F8 produce F1-F8, so no remap necessary.
+# Unmodified F9-F12 control brightness and volume.
+0x43 brightnessdown
+0x44 brightnessup
+0x57 volumedown
+0x58 volumeup
+
+# fn-modified fkeys all produce the unmodified version of the key.
+0xBB f1
+0xBC f2
+0xBD f3
+0xBE f4
+0xBF f5
+0xC0 f6
+0xC1 f7
+0xC2 f8
+0xC3 f9
+0xC4 f10
+0xD7 f11
+0xD8 f12
+
# Using F13-F21 for the .5 F keys right now.
0xF7 f13
=---------------------
paul fox, pgf@laptop.org
^ permalink raw reply related
* Re: Udev support for Ultima Cutter
From: Kay Sievers @ 2011-08-17 13:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAPVe_eAvd_o7kQMk8aQyJjKX_S-MUn0yMewJwz=Vs62900aWHA@mail.gmail.com>
On Wed, Aug 17, 2011 at 13:48, Olafur Arason <olafura@olafura.com> wrote:
> Hi, I need a udev rule file for Mutoh Ultima Cutter. It would be
> preferable if it links
> to /dev/cutter so I know which device to link to. This is a serial usb
> connection.
> I have previously managed to write data to this interface and have tried to make
> a rule file but I don't know why it does not work and the udevadm
> monitor interface
> does not give me any clues.
Check /dev/serial/* if there is a link already that fits?
Kay
^ permalink raw reply
* Udev support for Ultima Cutter
From: Olafur Arason @ 2011-08-17 11:48 UTC (permalink / raw)
To: linux-hotplug
Hi, I need a udev rule file for Mutoh Ultima Cutter. It would be
preferable if it links
to /dev/cutter so I know which device to link to. This is a serial usb
connection.
I have previously managed to write data to this interface and have tried to make
a rule file but I don't know why it does not work and the udevadm
monitor interface
does not give me any clues.
Regards,
Olafur Arason
lsusb -v output
Bus 002 Device 002: ID 0c30:6001
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0c30
idProduct 0x6001
bcdDevice 2.00
iManufacturer 1 MUTOH EUROPE NV
iProduct 2 ULTIMA CUTTER
iSerial 3 MECTKDPD
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 44mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 ULTIMA CUTTER
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Paul Fox @ 2011-08-17 3:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
karl o. pinc wrote:
> On 08/16/2011 05:54:04 PM, Daniel Drake wrote:
>
> > However, to complicate things further with another item on our TODO
> > list: OLPC offers the same identical laptop models with two alternate
> > keyboards - membrane and mechanical. This is for both x86 and ARM
> > models. At the moment, we use the same keymap for both even despite
> > differences in the keys, but we plan to improve on this in future
> > since it is a bug that keys do not behave according to the symbols
> > printed on them!
> >
> > There is no other difference in the laptop other than the keyboard,
> > so
> > this information could not be captured in the bare-bones info
> > presented in DMI or by the theoretical system mentioned above, unless
> > we were to do something hacky like encode the keyboard model in the
> > product_name.
>
> I don't understand.
>
> Why is it a hack to encode the keyboard model in the product name?
> When the keyboard is part of the product and there's two different
> keyboards (not just mechanically, but with different keymaps)
> why isn't it 2 product models?
we have three laptop models, and something like 20 different
keyboards. whether or not they all need different keymaps (they
don't), i think you can see why we might not necessarily encode any
of them as different models.
paul
=---------------------
paul fox, pgf@laptop.org
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Karl O. Pinc @ 2011-08-17 2:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On 08/16/2011 05:54:04 PM, Daniel Drake wrote:
> However, to complicate things further with another item on our TODO
> list: OLPC offers the same identical laptop models with two alternate
> keyboards - membrane and mechanical. This is for both x86 and ARM
> models. At the moment, we use the same keymap for both even despite
> differences in the keys, but we plan to improve on this in future
> since it is a bug that keys do not behave according to the symbols
> printed on them!
>
> There is no other difference in the laptop other than the keyboard,
> so
> this information could not be captured in the bare-bones info
> presented in DMI or by the theoretical system mentioned above, unless
> we were to do something hacky like encode the keyboard model in the
> product_name.
I don't understand.
Why is it a hack to encode the keyboard model in the product name?
When the keyboard is part of the product and there's two different
keyboards (not just mechanically, but with different keymaps)
why isn't it 2 product models?
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: Re: keymap rule selection for non-DMI platforms
From: Prarit Bhargava @ 2011-08-16 23:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On 01/-10/-28163 02:59 PM, Kay Sievers wrote:
> On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@kroah.com> wrote:
>> On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
>>> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>>> Sure, if there is something we all can use, we will switch over to it.
>>>> Until that happens, hacks have to be maintained by the people relying
>>>> on them, not by udev upstream.
>>>
>>> You can use it. Just like many platforms (of varying architectures)
>>> already do in other contexts, all using unmodified Linus kernels.
>>>
>>> Device tree is a well-documented cross-platform way of providing
>>> hardware identification information (and in great detail) to the
>>> kernel. I think it is the system you are asking for. Am I right in
>>> saying that its location in /proc is the main downfall that you are
>>> criticising it for? (i.e. would your viewpoint change if it appeared
>>> in /sys tomorrow?)
>>
>> What about all of the existing device tree work that has been going on
>> in the kernel for the past year? It should be in sysfs already, so why
>> not just use those files instead?
>>
>> As for DMI being "desktop" specific, others agree, and tried to write
>> patches to rename everything. I think they were rightly shot down as it
>> would have broken lots of userspace code, so there's no problem with
>> putting this type of information into the dmi "namespace" as it is.
That was me. Thanks Kay for pointing me to this thread.
The problem with the re-write was that people objected to a unified system interface in which different architecture's firmware could be exposed. The main issue was that the only two that "really" required this functionality were ia64 and x86. powerpc *could* make use of the interface but it wasn't a necessity as it is in the ia64 and x86 arches.
>
> Yeah, we should probably read it as "Digital Machine Identification"
> and just let all platforms export it. Stuff would magically just work
> out-of--the-box. :)
>
Kay, sometimes the best ideas come from jokes :) ... that doesn't sound as bad as you would think! Going back to my [v3] here
http://marc.info/?l=linux-kernel&m\x131099454831224&w=2
reworking the System Firmware Interface into a Digital Machine Identification layer would
a) resolve Paul's ARM problem discussed in this thread,
b) *DRAMATICALLY* cut down on the size of that patchset. 95% of it is s/DMI/SYSFW/g.
Paul -- what do you think? If I provided you a clean patchset in the next week or so would you be willing to implement the ARM functionality? Of course I would be more than willing to help ...
We could push it together and see where that goes.
P.
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Daniel Drake @ 2011-08-16 22:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 11:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> It has to fit into the way /sys is layouted, which is usually very
> different from /proc.
Right. And the challenge here is that devicetree sits above the
kernel's device layer (raising questions on exactly how to represent
it in /sys, without creating a container filesystem for /sys itself),
where DMI is (hackishly, IMO) exposed as a virtual device
(/sys/devices/virtual). Doing the same trick with DT would be bizarre
from the kernel standpoint.
> No, sorry, the time for dirty hacks in userspace, and work-arounds for
> architectures and platforms that don't provide what is commonly used
> elsewhere is over. There is no rush, it's new functionality, and no
> need to start with 'transitions periods' that in reality will never
> end. Stuff just needs to be fixed properly these days, and papering
> over just hurts us more in the end.
Not wanting to criticise any future unified system ideas, I just want
to point out that devicetree predates both udev and /sys. It is not
new. Your same arguments could be applied to DMI, which is new in
comparison, limited in the data it can represent, strangely exposed in
the kernel's representation of devices, and platform-specific. Yet DMI
and its imperfections already "won" udev, maybe just because of x86
popularity, so I guess that argument is not so interesting.
> The fix should be simple enough, we do not look for ACPI tree or the
> ARM device tree couterpart, we look for a simple, well-defined
> 'machine id' export. That's what class 'dmi' is on x86. Either ARM
> exports the same format, or we come up with something new for
> everybody which we all swich over to.
OK, now I think I understand what you are getting at. A generic sysfs
interface that could be fed by either (a part of) DMI or (a very small
part of) devicetree, which exposes bare-bones details like vendor and
product. That could indeed solve the problem at hand.
However, to complicate things further with another item on our TODO
list: OLPC offers the same identical laptop models with two alternate
keyboards - membrane and mechanical. This is for both x86 and ARM
models. At the moment, we use the same keymap for both even despite
differences in the keys, but we plan to improve on this in future
since it is a bug that keys do not behave according to the symbols
printed on them!
There is no other difference in the laptop other than the keyboard, so
this information could not be captured in the bare-bones info
presented in DMI or by the theoretical system mentioned above, unless
we were to do something hacky like encode the keyboard model in the
product_name. And, you guessed it, info on which type of keyboard is
installed comes from a devicetree node.
Daniel
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Kay Sievers @ 2011-08-16 22:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
>> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> > Sure, if there is something we all can use, we will switch over to it.
>> > Until that happens, hacks have to be maintained by the people relying
>> > on them, not by udev upstream.
>>
>> You can use it. Just like many platforms (of varying architectures)
>> already do in other contexts, all using unmodified Linus kernels.
>>
>> Device tree is a well-documented cross-platform way of providing
>> hardware identification information (and in great detail) to the
>> kernel. I think it is the system you are asking for. Am I right in
>> saying that its location in /proc is the main downfall that you are
>> criticising it for? (i.e. would your viewpoint change if it appeared
>> in /sys tomorrow?)
>
> What about all of the existing device tree work that has been going on
> in the kernel for the past year? It should be in sysfs already, so why
> not just use those files instead?
>
> As for DMI being "desktop" specific, others agree, and tried to write
> patches to rename everything. I think they were rightly shot down as it
> would have broken lots of userspace code, so there's no problem with
> putting this type of information into the dmi "namespace" as it is.
Yeah, we should probably read it as "Digital Machine Identification"
and just let all platforms export it. Stuff would magically just work
out-of--the-box. :)
Kay
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Kay Sievers @ 2011-08-16 22:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 22:49, Paul Fox <pgf@laptop.org> wrote:
> kay wrote:
> > On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
> > > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > >> Reading such things from /proc is kinda taboo from code we maintain in
> > >> udev. All things not related to processes really do not belong into
> > >> /proc and udev code should never get into the way of possibly
> > >> deprecating these things in the long run, even when they might never
> > >> happen. I know, there is sometimes no other simple option, but we
> > >> generally prefer the inconvenience it causes, over adding hacks to
> > >> upstream code, to make a move to a generally useful solution (which
> > >> isn't /proc/*) more attractive.
> > >
> > > I agree that the use of /proc is strange, but just to make sure you
> > > understand: /proc/device-tree is a standard upstream kernel thing and
> > > has been for a long time. It is not some OLPC-specific oddity to
> > > access our manufacturing data. It is *the* way to access device tree
> > > info on ARM, PPC, SPARC (and x86). And device tree is specifically
> > > built as a way of identifying hardware info which the silicon can't
> > > tell you. udev implementing support for device tree will solve OLPC's
> > > keyboard identification issue, but you'll also solve a whole class of
> > > problems for the wide range of platforms that use device tree (and
> > > those that will soon use it).
> >
> > That might all be true, I don't complain, it's just that udev upstream
> > does not read things like that from /proc, no matter how common the
> > use is.
> >
> > Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
> > can not read things like that from /proc because that would prevent
> > anybody from ever fixing it with the argument that one of the main
> > components relies on it.
>
> so just to be sure i understand your objection: if /proc/device-tree
> were to move to /sys/device-tree (or similar path,
It has to fit into the way /sys is layouted, which is usually very
different from /proc.
> and perhaps be
> doubly mounted there during a transition period)
No, we also don't accept double mount tricks here.
> it would be
> acceptable to propose that udev start using it?
No, sorry, the time for dirty hacks in userspace, and work-arounds for
architectures and platforms that don't provide what is commonly used
elsewhere is over. There is no rush, it's new functionality, and no
need to start with 'transitions periods' that in reality will never
end. Stuff just needs to be fixed properly these days, and papering
over just hurts us more in the end.
The fix should be simple enough, we do not look for ACPI tree or the
ARM device tree couterpart, we look for a simple, well-defined
'machine id' export. That's what class 'dmi' is on x86. Either ARM
exports the same format, or we come up with something new for
everybody which we all swich over to.
Kay
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Kay Sievers @ 2011-08-16 22:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 22:39, Daniel Drake <dsd@laptop.org> wrote:
> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Sure, if there is something we all can use, we will switch over to it.
>> Until that happens, hacks have to be maintained by the people relying
>> on them, not by udev upstream.
>
> You can use it. Just like many platforms (of varying architectures)
> already do in other contexts, all using unmodified Linus kernels.
>
> Device tree is a well-documented cross-platform way of providing
> hardware identification information (and in great detail) to the
> kernel. I think it is the system you are asking for.
We are not discussing the usefulness or completeness of any 'device
tree' here. That's an unrelated issue.
It's about a dead simple 'machine identification' that can be
retrieved without jumping through hoops.
x86 also does not need to look in the ACPI tree for matching up the
keymap, it has a simple interface to export hardware parameters in a
sane format. There is no reason other platforms can't do the same.
> Am I right in
> saying that its location in /proc is the main downfall that you are
> criticising it for? (i.e. would your viewpoint change if it appeared
> in /sys tomorrow?)
Sure, but probably not a single file, it can not move to /sys.
Kay
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Greg KH @ 2011-08-16 21:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > Sure, if there is something we all can use, we will switch over to it.
> > Until that happens, hacks have to be maintained by the people relying
> > on them, not by udev upstream.
>
> You can use it. Just like many platforms (of varying architectures)
> already do in other contexts, all using unmodified Linus kernels.
>
> Device tree is a well-documented cross-platform way of providing
> hardware identification information (and in great detail) to the
> kernel. I think it is the system you are asking for. Am I right in
> saying that its location in /proc is the main downfall that you are
> criticising it for? (i.e. would your viewpoint change if it appeared
> in /sys tomorrow?)
What about all of the existing device tree work that has been going on
in the kernel for the past year? It should be in sysfs already, so why
not just use those files instead?
As for DMI being "desktop" specific, others agree, and tried to write
patches to rename everything. I think they were rightly shot down as it
would have broken lots of userspace code, so there's no problem with
putting this type of information into the dmi "namespace" as it is.
greg k-h
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Paul Fox @ 2011-08-16 20:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
kay wrote:
> On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
> > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >> Reading such things from /proc is kinda taboo from code we maintain in
> >> udev. All things not related to processes really do not belong into
> >> /proc and udev code should never get into the way of possibly
> >> deprecating these things in the long run, even when they might never
> >> happen. I know, there is sometimes no other simple option, but we
> >> generally prefer the inconvenience it causes, over adding hacks to
> >> upstream code, to make a move to a generally useful solution (which
> >> isn't /proc/*) more attractive.
> >
> > I agree that the use of /proc is strange, but just to make sure you
> > understand: /proc/device-tree is a standard upstream kernel thing and
> > has been for a long time. It is not some OLPC-specific oddity to
> > access our manufacturing data. It is *the* way to access device tree
> > info on ARM, PPC, SPARC (and x86). And device tree is specifically
> > built as a way of identifying hardware info which the silicon can't
> > tell you. udev implementing support for device tree will solve OLPC's
> > keyboard identification issue, but you'll also solve a whole class of
> > problems for the wide range of platforms that use device tree (and
> > those that will soon use it).
>
> That might all be true, I don't complain, it's just that udev upstream
> does not read things like that from /proc, no matter how common the
> use is.
>
> Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
> can not read things like that from /proc because that would prevent
> anybody from ever fixing it with the argument that one of the main
> components relies on it.
so just to be sure i understand your objection: if /proc/device-tree
were to move to /sys/device-tree (or similar path, and perhaps be
doubly mounted there during a transition period), it would be
acceptable to propose that udev start using it?
paul
>
> >> I guess one sensible option is to register the /sys/class/dmi
> >> interface to ARM too, even when it's not called that way for ARM
> >> hardware. 'Desktop Management Interface' makes not much sense anyway,
> >> not even for x86, but hey it's only 3 characters, whatever they mean.
> >> :)
> >
> > I think you're too late to suggest a new solution to this problem.
> > This is exactly what device tree is for, and Linux has been steadily
> > going in this direction for a while.
>
> Sure, if there is something we all can use, we will switch over to it.
> Until that happens, hacks have to be maintained by the people relying
> on them, not by udev upstream.
>
> > However, the location inside of /proc is certainly something that can
> > be criticised.
>
> It's just nothing udev will use. Archs can do what they think it's
> right, and they might be right, I'll not argue here.
>
> But userspace should step back working around such things, and people
> should start working on the 'proper' solution.
>
> >> The alternative is to replace /sys/class/dmi with some completely arch
> >> and platform independent interface and export there what dmi currently
> >> supports and plug-in the other platforms.
> >
> > Device tree is already arch and platform independent, but I'm not sure
> > how you would make DMI info look like a device tree. Despite both
> > being able to provide identification info, they are quite different
> > beasts.
>
> Well, then upstream udev will wait for the common solution. :)
>
> Kay
=---------------------
paul fox, pgf@laptop.org
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Daniel Drake @ 2011-08-16 20:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Sure, if there is something we all can use, we will switch over to it.
> Until that happens, hacks have to be maintained by the people relying
> on them, not by udev upstream.
You can use it. Just like many platforms (of varying architectures)
already do in other contexts, all using unmodified Linus kernels.
Device tree is a well-documented cross-platform way of providing
hardware identification information (and in great detail) to the
kernel. I think it is the system you are asking for. Am I right in
saying that its location in /proc is the main downfall that you are
criticising it for? (i.e. would your viewpoint change if it appeared
in /sys tomorrow?)
Daniel
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Kay Sievers @ 2011-08-16 20:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
> On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Reading such things from /proc is kinda taboo from code we maintain in
>> udev. All things not related to processes really do not belong into
>> /proc and udev code should never get into the way of possibly
>> deprecating these things in the long run, even when they might never
>> happen. I know, there is sometimes no other simple option, but we
>> generally prefer the inconvenience it causes, over adding hacks to
>> upstream code, to make a move to a generally useful solution (which
>> isn't /proc/*) more attractive.
>
> I agree that the use of /proc is strange, but just to make sure you
> understand: /proc/device-tree is a standard upstream kernel thing and
> has been for a long time. It is not some OLPC-specific oddity to
> access our manufacturing data. It is *the* way to access device tree
> info on ARM, PPC, SPARC (and x86). And device tree is specifically
> built as a way of identifying hardware info which the silicon can't
> tell you. udev implementing support for device tree will solve OLPC's
> keyboard identification issue, but you'll also solve a whole class of
> problems for the wide range of platforms that use device tree (and
> those that will soon use it).
That might all be true, I don't complain, it's just that udev upstream
does not read things like that from /proc, no matter how common the
use is.
Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
can not read things like that from /proc because that would prevent
anybody from ever fixing it with the argument that one of the main
components relies on it.
>> I guess one sensible option is to register the /sys/class/dmi
>> interface to ARM too, even when it's not called that way for ARM
>> hardware. 'Desktop Management Interface' makes not much sense anyway,
>> not even for x86, but hey it's only 3 characters, whatever they mean.
>> :)
>
> I think you're too late to suggest a new solution to this problem.
> This is exactly what device tree is for, and Linux has been steadily
> going in this direction for a while.
Sure, if there is something we all can use, we will switch over to it.
Until that happens, hacks have to be maintained by the people relying
on them, not by udev upstream.
> However, the location inside of /proc is certainly something that can
> be criticised.
It's just nothing udev will use. Archs can do what they think it's
right, and they might be right, I'll not argue here.
But userspace should step back working around such things, and people
should start working on the 'proper' solution.
>> The alternative is to replace /sys/class/dmi with some completely arch
>> and platform independent interface and export there what dmi currently
>> supports and plug-in the other platforms.
>
> Device tree is already arch and platform independent, but I'm not sure
> how you would make DMI info look like a device tree. Despite both
> being able to provide identification info, they are quite different
> beasts.
Well, then upstream udev will wait for the common solution. :)
Kay
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Daniel Drake @ 2011-08-16 20:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Reading such things from /proc is kinda taboo from code we maintain in
> udev. All things not related to processes really do not belong into
> /proc and udev code should never get into the way of possibly
> deprecating these things in the long run, even when they might never
> happen. I know, there is sometimes no other simple option, but we
> generally prefer the inconvenience it causes, over adding hacks to
> upstream code, to make a move to a generally useful solution (which
> isn't /proc/*) more attractive.
I agree that the use of /proc is strange, but just to make sure you
understand: /proc/device-tree is a standard upstream kernel thing and
has been for a long time. It is not some OLPC-specific oddity to
access our manufacturing data. It is *the* way to access device tree
info on ARM, PPC, SPARC (and x86). And device tree is specifically
built as a way of identifying hardware info which the silicon can't
tell you. udev implementing support for device tree will solve OLPC's
keyboard identification issue, but you'll also solve a whole class of
problems for the wide range of platforms that use device tree (and
those that will soon use it).
> I guess one sensible option is to register the /sys/class/dmi
> interface to ARM too, even when it's not called that way for ARM
> hardware. 'Desktop Management Interface' makes not much sense anyway,
> not even for x86, but hey it's only 3 characters, whatever they mean.
> :)
I think you're too late to suggest a new solution to this problem.
This is exactly what device tree is for, and Linux has been steadily
going in this direction for a while.
However, the location inside of /proc is certainly something that can
be criticised.
> The alternative is to replace /sys/class/dmi with some completely arch
> and platform independent interface and export there what dmi currently
> supports and plug-in the other platforms.
Device tree is already arch and platform independent, but I'm not sure
how you would make DMI info look like a device tree. Despite both
being able to provide identification info, they are quite different
beasts.
Daniel
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Kay Sievers @ 2011-08-16 19:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
On Tue, Aug 16, 2011 at 20:54, Paul Fox <pgf@laptop.org> wrote:
> since my initial query was met with such enthusiastic silence :-),
Yeah, I guess we all mostly focus on x86 and similar.
> i've decided to try another approach. attached is a (very tentative)
> patch that supports our non-DMI laptop using a familiy-identifying
> attribute found in /proc/device-tree.
>
> essentially it adds a utility (currently in shell, but which will
> trivially turn into C) that facilitates forming environment keys from
> device-tree nodes. this is then used in 95-keymap.rules to detect an
> XO laptop and apply the right keymap. the device-tree has always been
> under /proc on linux -- it would probably make more sense under /sys,
> but i'm not sure about the effort needed for, or the ramifications of,
> such a move.
Reading such things from /proc is kinda taboo from code we maintain in
udev. All things not related to processes really do not belong into
/proc and udev code should never get into the way of possibly
deprecating these things in the long run, even when they might never
happen. I know, there is sometimes no other simple option, but we
generally prefer the inconvenience it causes, over adding hacks to
upstream code, to make a move to a generally useful solution (which
isn't /proc/*) more attractive.
I guess one sensible option is to register the /sys/class/dmi
interface to ARM too, even when it's not called that way for ARM
hardware. 'Desktop Management Interface' makes not much sense anyway,
not even for x86, but hey it's only 3 characters, whatever they mean.
:)
The alternative is to replace /sys/class/dmi with some completely arch
and platform independent interface and export there what dmi currently
supports and plug-in the other platforms.
I'm very convinced that userspace should not even try to work around
platforms that miss proper interfaces which can be used to easily
match against system properties.
Kay
^ permalink raw reply
* Re: keymap rule selection for non-DMI platforms
From: Paul Fox @ 2011-08-16 18:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>
i wrote:
> hi --
>
> OLPC's latest laptop (the 1.75 model) is ARM-based. this means the
> current keymap rule in rules.d/95-keymap.rules:
>
> ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", \
> RUN+="keymap $name olpc-xo"
>
> won't trigger -- there's no DMI information.
>
> any thoughts on how non-PC hardware should be identifying itself
> to udev? are there other examples of how this might be done?
>
> i'm sure we could come up with something, based on examining some
> other sysfs attribute, or perhaps running a command which identifies
> our laptop(s), but i suspect this issue has come up before.
>
since my initial query was met with such enthusiastic silence :-),
i've decided to try another approach. attached is a (very tentative)
patch that supports our non-DMI laptop using a familiy-identifying
attribute found in /proc/device-tree.
essentially it adds a utility (currently in shell, but which will
trivially turn into C) that facilitates forming environment keys from
device-tree nodes. this is then used in 95-keymap.rules to detect an
XO laptop and apply the right keymap. the device-tree has always been
under /proc on linux -- it would probably make more sense under /sys,
but i'm not sure about the effort needed for, or the ramifications of,
such a move.
like i said, the attached constitutes a strawman approach. hopefully
it will generate some thumbs, either up or down.
paul
commit ec4edb170cde845c7f710d98d7aceab2db729c53
Author: Paul Fox <pgf@laptop.org>
Date: Tue Aug 16 14:26:55 2011 -0400
tentative support for using device-tree attributes to identify a platform
the new script device-tree-val is used in 95-keymap.rules to identify
an OLPC XO laptop, based on the contents of /proc/device-tree/compatible
diff --git a/extras/device-tree/device-tree-val b/extras/device-tree/device-tree-val
new file mode 100644
index 0000000..46c884a
--- /dev/null
+++ b/extras/device-tree/device-tree-val
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+dtree=/proc/device-tree
+
+usage()
+{
+ echo ${0##*/} key path >&2
+ exit 1
+}
+
+test $# = 2 || usage
+
+key="$1"
+path="$2"
+
+# 2nd arg must exist and be readable
+: < $dtree/$path || exit 1
+
+echo $key=$(cat $dtree/$path)
+
+
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 0d9b771..36d5d19 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -40,7 +40,7 @@ GOTO="keyboard_end"
LABEL="keyboard_modulecheck"
ENV{DMI_VENDOR}="$attr{[dmi/id]sys_vendor}"
-ENV{DMI_VENDOR}="", GOTO="keyboard_end"
+ENV{DMI_VENDOR}="", GOTO="keyboard_devicetree"
ENV{DMI_VENDOR}="IBM*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Buttons", RUN+="keymap $name module-ibm"
ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Buttons", RUN+="keymap $name module-lenovo"
@@ -156,5 +156,11 @@ ENV{DMI_VENDOR}="Everex", ATTR{[dmi/id]product_name}="XT5000*", RUN+="keymap $
ENV{DMI_VENDOR}="COMPAL", ATTR{[dmi/id]product_name}="HEL80I", RUN+="keymap $name 0x84 wlan"
ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", RUN+="keymap $name olpc-xo"
+GOTO="keyboard_end"
+
+LABEL="keyboard_devicetree"
+
+IMPORT{command}="device-tree-val DEVTREE_COMPAT compatible"
+ENV{DEVTREE_COMPAT}="olpc,xo-1*", RUN+="keymap $name olpc-xo"
LABEL="keyboard_end"
=---------------------
paul fox, pgf@laptop.org
^ permalink raw reply related
* Input devices issue with kernel 2.6.37
From: Yegor Yefremov @ 2011-08-15 12:49 UTC (permalink / raw)
To: linux-hotplug
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?
Yegor
^ 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