Hi, just to be noted, that is not required to boot with openSUSE. Any nmodern Linux is enough, that is that there should be is the /sys file system and the filled /dev/input/ directory. I'd like to know the output of for n in /dev/input/event*; do udevadm info -a --name=$n done then we might catch the input device for gpio-keys.8 and the power switch therein. Werner
Le 01/10/2014 14:35, Andreas Färber a écrit :
Hi, Let's CC opensuse-arm for such ARM questions... Am 30.09.2014 um 09:29 schrieb Dr. Werner Fink:
Hi, just to be noted that the patch rules-add-lid-switch-of-ARM-based-Chromebook-as-a-power-sw.patch which includes the line SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="gpio-keys.8", TAG+="power-switch" in the 70-power-switch.rules can not be fully corect. This because the "gpio-keys.8" is much to general and may cause trouble with other keyboard layouts. Therefore I'd like to see the output of such a Chromebook of the command: udevadm info -a /dev/input/by-path/*kbd which may give the more specific name of the power button.
Werner
Alex? Guillaume? Can any of you provide the requested information for the Samsung Chromebook?
From Chrome OS (kernel 3.8.11), "udevadm info -a --name=/dev/input/by-path/*kbd" returns: ********************************************************************** 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/12ca0000.i2c/i2c-4/i2c-104/104-001e/cros-ec-keyb.3/input/input0/event0': KERNEL=="event0" SUBSYSTEM=="input" DRIVER==""
looking at parent device '/devices/12ca0000.i2c/i2c-4/i2c-104/104-001e/cros-ec-keyb.3/input/input0': KERNELS=="input0" SUBSYSTEMS=="input" DRIVERS=="" ATTRS{name}=="cros-ec-i2c" ATTRS{phys}=="i2c-4-mux (chan_id 0)" ATTRS{uniq}=="" ATTRS{properties}=="0"
looking at parent device '/devices/12ca0000.i2c/i2c-4/i2c-104/104-001e/cros-ec-keyb.3': KERNELS=="cros-ec-keyb.3" SUBSYSTEMS=="platform" DRIVERS=="cros-ec-keyb"
looking at parent device '/devices/12ca0000.i2c/i2c-4/i2c-104/104-001e': KERNELS=="104-001e" SUBSYSTEMS=="i2c" DRIVERS=="cros-ec-i2c" ATTRS{name}=="cros-ec-i2c"
looking at parent device '/devices/12ca0000.i2c/i2c-4/i2c-104': KERNELS=="i2c-104" SUBSYSTEMS=="i2c" DRIVERS=="" ATTRS{name}=="i2c-4-mux (chan_id 0)"
looking at parent device '/devices/12ca0000.i2c/i2c-4': KERNELS=="i2c-4" SUBSYSTEMS=="i2c" DRIVERS=="" ATTRS{name}=="s3c2410-i2c"
looking at parent device '/devices/12ca0000.i2c': KERNELS=="12ca0000.i2c" SUBSYSTEMS=="platform" DRIVERS=="s3c-i2c" **********************************************************************
My openSUSE SD card is currently broken, so I cannot test under openSUSE.
Independent of the exact GPIO key, the term "ARM based Chromebook" in the subject and patch name seems to be rather broad given that there's the original Samsung Chromebook, plus the HP Chromebook 11, plus an Acer Chromebook based on Tegra, plus some based on Rockchip, etc. which likely all use different GPIO configurations.
Mine is a Samsung Chromebook.
Guillaume
-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr