Code: Select all
System: Host: <whatever> Kernel: 5.4.0-89-generic x86_64 bits: 64 Desktop: MATE 1.24.0 Distro: Linux Mint 20.2 Uma
Machine: Type: Laptop System: ASUSTeK product: ZenBook UX325JA_UX325JA v: 1.0 serial: <superuser/root required>
Mobo: ASUSTeK model: UX325JA v: 1.0 serial: <superuser/root required> UEFI: American Megatrends v: UX325JA.309
date: 04/26/2021
Battery: ID-1: BAT0 charge: 34.0 Wh condition: 67.8/67.1 Wh (101%)
CPU: Topology: Quad Core model: Intel Core i5-1035G1 bits: 64 type: MT MCP L2 cache: 6144 KiB
Speed: 1300 MHz min/max: 400/3600 MHz Core speeds (MHz): 1: 1300 2: 1300 3: 1300 4: 1261 5: 1300 6: 1300 7: 1300
8: 1300
Graphics: Device-1: Intel driver: i915 v: kernel
Display: x11 server: X.Org 1.20.11 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel UHD Graphics (ICL GT1) v: 4.6 Mesa 21.0.3
Audio: Device-1: Intel Smart Sound Audio driver: snd_hda_intel
Sound Server: ALSA v: k5.4.0-89-generic
Network: Device-1: Intel Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter driver: iwlwifi
IF: wlo1 state: up mac: <whyareyouasking>
Drives: Local Storage: total: 238.47 GiB used: 48.30 GiB (20.3%)
ID-1: /dev/nvme0n1 vendor: Western Digital model: PC SN530 SDBPNPZ-256G-1002 size: 238.47 GiB
Partition: ID-1: / size: 49.72 GiB used: 10.63 GiB (21.4%) fs: ext4 dev: /dev/nvme0n1p6
ID-2: /home size: 109.50 GiB used: 3.29 GiB (3.0%) fs: ext4 dev: /dev/nvme0n1p7
Sensors: System Temperatures: cpu: 49.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 259 Uptime: 7h 16m Memory: 7.45 GiB used: 2.39 GiB (32.1%) Shell: bash inxi: 3.0.38
Reaching the UEFI-BIOS to change the booting drive is achieved with F2.
Note: you may achieve this with F12 as well but it takes you through the WIN10 UEFI menus that are quite convoluted.
The step where you need to decide where to install your linux, I chose manual repartitioning. I reduced the main NTFS partition to 80Gb, and created a 50Gb root '/' ext4 and a 120 Gb '/home' ext4 partitions.
The install procedure was typical in that it went very smoothly through the 20.1 disk image install, then the full upgrade to 20.2.
Almost everything works out of the box, except a couple important topics:
- brightness control does not work at all. One alleged reason is that OLED screens don't have backlights, and the driver does not support adjusting that parameter. I have found a good-enough workaround (for single user), detailed below.
- suspend/hibernate results in the laptop hanging when waking up: again I have found a workaround, and it's not perfect.
I. Overcoming the brightness adjustment problem
Searching the web yields a couple results that seem to work (brightnessct, monitor-brightness), more or less adequate but not passing the test of time & failed as soon as de-hibernating. Instead, I'm using little bash scripts that implements a nice-but-a-bit-dangerous feature of
xrandr.The
xrandr way of adjusting brightness is the --brightness option, followed by a float number between 0 and 1. For example, to set brightness at 70% maximum, you'd do:
xrandr --output eDP-1 --brightness 0.7 If you're trying this on another laptop model, please note you should make sure you get the output display right by looking at the result of
xrandr | grep primaryThe first few characters are the name of your primary screen, here eDP-1, by default defined as that attached to the laptop.
So here are the two bash scripts, one to up the brightness in fixed steps, while checking it does not go beyond limit (strange results on OLED):
Code: Select all
#!/bin/bash
# upbright increases screen brightness in fixed steps
B="$(echo $(xrandr --verbose | grep Brightness | grep -o '[[:digit:]]\+.\+'))"
if [ $(echo "$B < 1" | bc) -eq 1 ]
then
B="$(echo "$B + 0.05" | bc)"
fi
xrandr --output eDP-1 --brightness $B
Code: Select all
#!/bin/bash
# down the brightness in proportional steps
B="$(echo $(xrandr --verbose | grep Brightness | grep -o '[[:digit:]]\+.\+'))"
if [ $(echo "$B > 0.05" | bc) -eq 1 ]
then
B="$(echo "$B * 0.9" | bc)"
fi
xrandr --output eDP-1 --brightness $B
The last step is to link them to a keyboard shortcut, such as 'Ctrl+down' and 'Ctrl+Up' with the dedicated desktop tool (search 'shortcut' in main menu, or launch mate-keybinding-properties). For safety, as I was testing the scripts, I found it useful to have an additional keyboard shortcut with the above
xrandr instruction for 70% brightness.II. The hell of ACPI: sleep and hibernation
Low-power management seems to be very complex and I have no understanding of it at all. It seems to follow a kind of standard named ACPI for Advanced Configuration and Power Interface, which behaves in a very conventional way as far as standards go: not everyone does it the same way.
There are various levels of de-activation of the laptop when it goes low-power, and that's negotiated between the OS and the BIOS. Now with this laptop's BIOS and Linux Mint 20.2, out-of-the-box, they seem to agree on how to go to sleep. The problem happens when they try to get up... it's a big hangover, and you'll have to hard-stop the laptop by pressing the power button for 15s before it does anything.
The workaround I found requires careful manipulation of a system file with a text editor in superuser mode.
Code: Select all
sudo nano /etc/default/grubCode: Select all
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"mem_sleep_default=deep so it looks :
Code: Select all
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"Before the config file is actually activated, you need to perform the following command:
Code: Select all
sudo update-grubNow, if you read a bit about the
deep state in ACPI, it is supposed to suspend to RAM, and the battery will discharge somewhat in that mode. As this suspend mode keeps the RAM refreshed and does not back it up to disk like hibernation usually means, to be on the safe side save your data ahead of closing the lid. At least you don't get a frozen PC like out-of-the-box suspend.Hope this'll save some time to other people!
