The laptop is ASUS FX503vd, I tried several versions of Linux kernels (currently running one is the 4.17.1), but still have not managed to make the keyboard backlight control keys work. After the system boot on, the backlight is always on. There are two function keys (reused the numerical keypad) which is to control the brightness of the backlight. In windows, I can adjust down its brightness until fully off. But pressing the same keys in Linux has no effect at all. My feeling is the kernel did not detected the corresponding WMI device
Below is the /sys/devices/platform/asus-nb-wmi/ contents:
~ $ ls /sys/devices/platform/asus-nb-wmi/
cpufv driver_override input/ power/ uevent
driver# hwmon/ modalias subsystem#
And, below is the kernel message filtered by 'asus' keyword: (i.e. dmesg |grep 'asus')
[ 6.698065] asus_wmi: ASUS WMI generic driver loaded
[ 6.700669] asus_wmi: Initialization: 0x1
[ 6.700723] asus_wmi: BIOS WMI version: 8.1
[ 6.700764] asus_wmi: SFUN value: 0x4a0061
[ 6.701323] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input10
[ 6.703080] asus_wmi: Number of fans: 1
Does anyone have some clues about the laptop keyboard issue?
Does the driver depend on the layout of the keyboard?
Thanks in advance.
-woody
Here is guid in kernel Documentation in Documentation/laptops/asus-laptop.txt.
According to that follow the steps to enable this functionality.
modprobe asus-laptop (check dmesg)
You can control lcd backlight power and brightness with
/sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15.
I hope you did it somehow but for those who didn't managed to do it, there is a little advice
!!! This works only on ubuntu based distros !!!
You will probably have to install newer kernel (which is not in repository for everyone to install). That may help you with much more problems like backlight issues or so.
You can look at this answer. There is written how to update your current kernel. kernel versions are not up to date so you'll have to choose some higher version.
I hope this helps :)
Related
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
I'm running into a very strange issue attempting to run CodeSys on a 4GB RasPi-4. Long story short, the Pi works fine right up until I start running the CodeSys project. When I do, within 60sec, eth0 goes down and cannot be brought back up. Even rebooting the Pi has no effect. The only way I've found to recover eth0 is to re-burn RasPiOS from the source image from Raspberrypi.org (which I've done about 30 times over the past few days, trying to trial-and-error my way out of this).
Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
I have eth0 set to a static IP using /etc/dhcpcd.conf. Whatever is causing this issue is not altering my settings there. Attempts to use ifconfig eth0 up/down have no effect -- no errors, no feedback, just nothing. Checking eth0's state shows "waiting for carrier," despite being connected to an active switch (I've also swapped out all the cables and the switch to eliminate them as the source of the problem).
When I re-burn the Pi and install CodeSys, eth0 stays up indefinitely (24hrs+ in my longest test). It's starting the CodeSys project that kills eth0. A reboot after etho "dies" gives a series of bcmgenet messages that appear to be related:
pi#raspberrypi:~ $ dmesg | grep bcmg
[ 1.033665] bcmgenet fd580000.ethernet: failed to get enet clock
[ 1.033685] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 1.033709] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[ 1.033730] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[ 1.044648] libphy: bcmgenet MII bus: probed
[ 9.528502] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[ 9.535175] bcmgenet fd580000.ethernet eth0: Link is Down
I also tried creating a new CodeSys project from scratch that had no eth0 drivers (ModBus, Ethernet/IP) installed, only the GPIO driver. That didn't help either -- eth0 dies within 60sec.
The strangest part is, only eth0 seems to be affected. The GPIO pins keep cycling as controlled by the CodeSys project (I have a simple LED-blinking program running), and I can still SSH into the Pi using wifi. But since my main reason for setting this Pi up is to use Ethernet/IP and ModBus....
This thread: at GitHub is the only place I've found anyone describing anything similar to what I'm experiencing, but in that case CodeSys is not installed. I did try adding genet.skip_umac_reset=n to my cmdline.txt as suggested in the thread, but it had no effect.
So, it turned out this was an issue configuring the GPIO pins.
CodeSys has two difference "device" files for adding the GPIO pins to the project device tree. The default selection is for older Pi models, and the alternate choice (labelled only for B+ and Pi2) is the correct one for the Pi4.
As it turns out, the outdated GPIO device file will work on a Pi4, mostly. But using the wrong device file allows CodeSys to try configuring GPIO pins that shouldn't be tampered with. In this case, GPIO 28 and 29. Setting either of them to Output mode killed eth0.
Using the correct device file removes 28&29 from the list of configurable GPIO pins. It also gives the correct list of available GPIO pins for the newer Pi models, hopefully avoiding other potential config issues that I didn't trip over.
In CodeSys, right-clicking on the GPIOs element in the device tree offers the option to "Update the Device." Select this option to get the list of available device files, and select the correct one before using the "Update Device" button in the bottom of the window.
On a Raspberry PI 3B+, it's simple to turn power on its four USB ports off and on. Simply write a "0" to /sys/devices/platform/soc/3f980000.usb/buspower to turn power off and a "1" to turn power on.
The same method doesn't work on Raspberry PI 4B, 4GB (the hex number before ".usb" is different, that's NOT the problem). I have tried uhubctl and hub-ctl as well without any success. I have used a USB power meter to measure the voltage on the ports. It doesn't change. Un a PI 3B+ it changes as expected.
Does the PI 4 support turning USB power off and on in software at all? If it does, how to do it? Or is there a bug somewhere that has to be fixed to make it work? I use the newest Rapbian on both the Pi 3B+ and the Pi 4.
Yes, uhubctl supports RPi4B, I have recently added support for it - you need to use uhubctl version 2.4.0 or later (or build it from master branch). It is also necessary to update USB firmware using sudo rpi-eeprom-update to make power switching actually work.
Note that you are missing out by using sysfs method to turn USB off on RPi3B+ - using uhubctl you can control either all 4 ports, or 2 of them independently. RPi4B only supports turning off all ports at once.
As far as I read Raspberry Pi and Linux issues on GitHub, it seems that there was a bugfix released for uhubctl on 2019 July. Patch I'm refering to: mvp/uhubctl#4aae44c. It should be merged to master. So...
Another thing to have in mind, it seems that RRi 4B hardware only supports "ganged power switching", which means... that You can only turn on and off ALL the USB ports. Not every single one in particular.
To shut off power for USB ports and Ethernet type the following into the Raspberry Pi Terminal and press enter:
echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/unbind
For that you need to install:
sudo apt-get install uhubctl
For turn on again use this command:
echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/bind
I'm trying to get MSI-X working on an iMX6 (Freescale/NXP/Qualcomm) CPU in Linux v4.1 for a PCIe character device driver. Whenever I call either pci_enable_msix() or pci_enable_msix_range() or pci_enable_msix_exact() I get an EINVAL value returned. I do have the CONFIG_PCI_MSI option selected in the kernel configuration and I am also able to get single MSI working with pci_enable_msi(), but I cannot get multiple MSI working either.
I have tested my driver code on an Intel i7 running kernel v3 with the same PCIe hardware attached and I was able to get MSI-X working without any problems so I know my code is correctly written and the hardware is correctly functioning.
When running on the iMX6 I can use lspci -v to view that the hardware has MSI-X capabilities and see the number of IRQs it allows. I can even get the same correct number in my driver when calling pci_msix_vec_count().Questions
Are there any other kernel configuration flags I need to set?
Is there anything specific to the iMX6 CPU I need to consider?
Does anyone have any experience with the iMX6 and either MSI-X or
multiple MSI?
I have Hackintosh build by a friend back in 2012. I need some files from it now but I can not access it. I see white screen after I login with my infos. Mouse and keyboard works but I only see white screen. I get to see wallpaper background with login when I press Power button. But when I login only whites screen. Im using HDMI on dedicated GTX 670. I also tried DVI without luck - same white screen after login. I pull out GTX out and RAM memory. No any differences. I tried different options on boot. -v -s (-f i can not log with). Also tried GraphicsEnabler=On/Off. I just need some files from Drives and then I can wipe out the system. Can you help me and tell if you have experience to solve this problem?
Specs:
Darwin/x86 boot v5.0.132 - Chimera v1.8.0
16 GB RAM
Intel i7-2600 #3.40Ghz
NVIDIA GeForce GTX 560
Lion OSX
Take out your HDD/SSD drive from the hackintosh and connect it to any Mac with a USB to SATA adapter. (If you have another hackintosh, just plug the drive to the other PC).
Note that regular 3.5" hard disks require a powered USB to SATA adapter, because these drives are unable to power with a single USB port.