I have a new laptop (Samsung NP900X3C) and am setting it up with Linux. Most things work fine, some don't out of the box but I managed to fix them. Some baffle me to no end...
chmod 777 doesn't seem to work on rfkill
You can set the things like brightness by echoing numbers to /sys/devices/platform/samsung/leds/samsung::kbd_backlight/brightness. To make this possible without root rights, I added "chmod 777 /sys/devices/platform/samsung/performance_level" to /etc/rc.d/boot.local to allow users to set this. Simply works.But not everything is as fluffy bunny as it should be.
- First, I know 'chmod 777' is a tad rude. What should be safer?
- Second, when I do the very same thing (chmod 777) to /sys/devices/platform/samsung/rfkill/rfkill0/state (or /soft), I still get
- echo 1 > /sys/devices/platform/samsung/rfkill/rfkill0/state
bash: echo: write error: Operation not permitted
can't asign keys
I am unable to use the Fn F9 and Fn F10 keys to adjust brightness. These keys have no keycodes asigned to them but a simple 'setkeycodes e016 237' etc in boot.local takes care of that. Now, xev should be able to see these keys and I should be able to use them, right? Nope... The kernel has stopped telling me the keys have no keycodes but they still don't show up :(Even weirder, the Fn F12 key (wlan) doesn't even show a kernel message that it has no keycode but doesn't show up in xev either.
However, while mucking around with these keys, occasionally the terminal (or any other app) gets suddenly filled with a stream of characters (often @ or ±) and the mouse sometimes stops working and I have to (re)start synaptiks to get things working.
U no Power?
The kernel doesn't notice if the laptop is on power or not, nor does it give off any indications if the laptop lid is closed. The relevant acpi files in /proc (/proc/acpi/ac_adapter/ADP1/state and /proc/acpi/button/lid/LID0) don't change anymore after booting. It's a bit of a pain, does anyone know where these are set and if there's any way I can fix it (and where to send that fix)?Segfaults in synaptiks
Last but not least, while I'm at it - anyone know if synaptiks is supposed to segfault after resuming from suspend-to-ram?!? The app is awesome and I wouldn't be able to use a laptop with a touchpad without it. The segfaulting is a tad annoying, though.All this on openSUSE 12.2 RC 2, btw. That runs Linux Kernel 3.4.6. Once I've set everything up and fixed these issues I'll make a post with tips, tricks and some scripts to get the most out of this laptop ;-)
> First, I know 'chmod 777' is a tad rude. What should be safer?
ReplyDeleteI would recommend for files: chgrp users ; chmod 664
> echo 1 > /sys/devices/platform/samsung/rfkill/rfkill0/state
> bash: echo: write error: Operation not permitted
It is getting a permission error on the write instead of the open as you would get for forbidden files.
http://minerva.netgroup.uniroma2.it/svn/discreet/tfcproject/trunk/linux-2.6.23.12-TFC/net/rfkill/rfkill.c
shows a check for capable(CAP_NET_ADMIN)
and normally, only root has any of those capabilities.
The power and lid things might need drivers or kernel patches. Or maybe BIOS updates could help?
Hm, I can not say anything specific about Samsung laptops, but there may be different reasons. First you should check if there is samsung kernel module and if it is loaded correctly. May be there are also different ones and you need to find out which one you need. If the problem lies here, you may find the solution for all the problems. Then there is the possibility of selecting a different keyboard layouts. I do not know about Opensuse but in Kubuntu it can be selected on installation. May be there is a better one compared to the one which was automatically selected.
ReplyDeleteThe problem with keys which can not be assigned may also have something to do with qt and or the xserver. At least that is what I was told for my Thinkpad There is not enough "space" for all combinations so some don't work. Unfortunately KDE lacks a simple tool for configuring special laptop keys :-(
About the crash after suspend: If your laptop is intel, there was a bug with suspend which was fixed only recently and may be the cause of your problem.
The battery plasmoid uses polkit to set the brightness or a helper suid program when polkit does not work. You should not need to do any chmod'ing. Anyway, you can use sudo to allow a specific user or group to execute a specific command. You just need something like this in /etc/sudoers:
ReplyDelete%wheel LOCALHOST=NOPASSWD:
=====
keycodes are used by the kernel, Xorg uses keysyms. If a key does not have a keysym associated to it then Xorg cannot use it (even if the kernel can). The bad news is that the keysym also has to have a enum in Qt to be used by any Qt program (https://bugs.kde.org/show_bug.cgi?id=182672)
=====
what does 'upower -d' return? The line with 'online: ' indicates if the computer is on power or not. 'lid-is-closed: ' indicates lid state. The laptop lid is based on ACPI, if it is not working then there will be no event to upower and consequently to PowerDevil.
=====
I do not use Synaptiks, so I cannot help much here. The crashlog would be helpfull.
The screen backlight works, it's the keyboard one that doesn't I've got the keys fixed now (following a how-to adding stuff to udev) but nothing happens upon using them. Do you happen to know if anything in a Plasma workspace is supposed to react to that or do we not support that at all? GNOME Shell is supposed to take care of it but I haven't tested that yet.
DeleteFollowing Lamarque advise, I would start to add your user to wheel group
ReplyDeleteand look for any samsung or acpi module that can help
here's there some good candidate
find /lib/modules/ -iname "*samsung*"
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/platform/x86/samsung-laptop.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/platform/x86/samsung-q10.ko
find /lib/modules/ -iname "*acpi*"
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/ata/pata_acpi.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/acpi
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/acpi/acpi_pad.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/acpi/acpi_ipmi.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/acpi/acpi_memhotplug.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/platform/x86/toshiba_acpi.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/platform/x86/thinkpad_acpi.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/pci/hotplug/acpiphp_ibm.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/pci/hotplug/acpiphp.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/cpufreq/acpi-cpufreq.ko
/lib/modules/3.1.10-1.16-desktop/kernel/drivers/hwmon/acpi_power_meter.ko
/sbin/modinfo samsung-laptop
filename: /lib/modules/3.1.10-1.16-desktop/kernel/drivers/platform/x86/samsung-laptop.ko
license: GPL
description: Samsung Backlight driver
author: Greg Kroah-Hartman
srcversion: F0C9A569403AD48169F5B22
alias: dmi*:svn*SAMSUNGELECTRONICSCO.,LTD.*:ct*14*:
alias: dmi*:svn*SAMSUNGELECTRONICSCO.,LTD.*:ct*10*:
alias: dmi*:svn*SAMSUNGELECTRONICSCO.,LTD.*:ct*9*:
alias: dmi*:svn*SAMSUNGELECTRONICSCO.,LTD.*:ct*8*:
depends: rfkill
vermagic: 3.1.10-1.16-desktop SMP preempt mod_unload modversions
parm: force:Disable the DMI check and forces the driver to be loaded (bool)
parm: debug:Debug enabled or not (bool)
once you have them working modprobe -v as root
you will be able to add then in /etc/sysconfig/kernel file so they will also be reloaded and inserted in the initrd
I am not sure if this is related to your problem as my laptop is not a Samsung, but to get my laptop function keys and other power related things working I had to try different values for acpi_osi on the kernel command line in GRUB.
ReplyDeleteFor me the one that worked was having acpi_osi= (no value - tried other values that didn't work, leaving it out altogether also didn't work)
Not sure if that's the best way to work around those problems but it seemed to work for me...
Hi there,
ReplyDeleteI got most of the keys working by following the steps of
http://jablonskis.org/2012/linux-and-samsung-series-laptop-9-fn-keys/
and the previous post that is listed at the top of the linked one.
Just be sure to check the udev rule files and replace "*90X3A*" with "*900X3C*" (I actually own a 900X4C).
Regarding the power thing, see here, and help if you can :)
https://bugzilla.kernel.org/show_bug.cgi?id=44161
And from Lennart Poettering on G+:
ReplyDeleteThe special keycodes should be added to systemd/udev so that they are automatically applied based on DMI info, i.e. somewhere here:
http://cgit.freedesktop.org/systemd/systemd/tree/keymaps
applied with this rules file:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/keymap/95-keymap.rules
For more information see:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/keymap/README.keymap.txt
Thanks all for the comments, I'll go play with this when I have time and will integrate it in the final blog post (provided I figure it all out) or ask either some of you directly or via a blog post again (if I didn't) :D
I'm in the process of trying to upstream a patch that makes udev recognising our newer model for applying the correct keymap rules.
ReplyDeleteWill let you know :)
See here, and if you could test the patch that would be sweet!
Deletehttps://bugs.freedesktop.org/show_bug.cgi?id=53243
I added the changes from here:
Deletehttps://bugzilla.redhat.com/show_bug.cgi?id=838036
As far as I can tell (but I might be wrong) you describe different keycodes - so that would mean it's not correct.. For example, the performance mode is not under Fn-F1 but onder Fn-F11 with keycode 0xB3 (the Fn F1 has the samsung settings app under it on my laptop). Moreover, the keyboard backlight buttons are F9 and F10, not F7 and F8...
I see,
Deletethough most of those keys work on my 900X4C without patching udev. Those that do not work are F1 for the settings, F9-F10 for the keyboard brightness, F11 for the performance mode and F12 for the wifi. The keycodes for these ones in the bugzilla entry linked by you are the same of the respective keys for the 90X3A, no matter what the FN keys they are assigned to. You can check that the keycodes match if you look at what you have in samsung-90xa. I do not know why I don't need keycodes for the LCD brightness, volume keys, etc., kind of mistery.
Anyway, it would be great if our models could be recognised by udev without further action, and thanks a lot for pointing me to the Red Hat bugzilla, maybe we should add such link to my upstream report.