Using xrandr disables keyboard/mouse/touchpad input on Lenovo Ideapad 330

feb11 · 03-03-2021, 10:17 AM

Debian 10 stable buster
kernel 4.19.0-12-amd64
The problem: in X-window, any of the following two commands

Code:

xrandr --output eDP --brightness 0.35
xrandr --output eDP --mode 1024x768

disable keyboard/mouse/touchpad input (I still can move the mouse pointer but clicks don't have any
effect). Which makes X unusable and I have to kill xorg from another terminal.

Related packages that I installed:
firmware-linux firmware-linux-nonfree libdrm-amdgpu1 xserver-xorg-video-amdgpu
firmware-amd-graphics libgl1-mesa-dri libglx-mesa0 mesa-vulkan-drivers xserver-xorg-video-all
xserver-xorg-input-synaptics
(Prior to installing them, xrandr wouldn't work at all, "unknown gamma" message or some such)

I wonder what the problem is and how I can fix it
Thanks

My video hardware:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5
Graphics] (rev d2) (prog-if 00 [VGA controller])
Subsystem: Lenovo Stoney [Radeon R2/R3/R4/R5 Graphics]
Flags: bus master, fast devsel, latency 0, IRQ 37
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f0000000 (64-bit, prefetchable) [size=8M]
I/O ports at 3000 [size=256]
Memory at f0d00000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: amdgpu
Kernel modules: amdgpu

floppy_stuttgart · 03-05-2021, 04:10 AM

My thoughts..
1. Update your BIOS? https://www.reddit.com/r/kernel/comm...s_ubuntu_1804/
2. Arch looks ok for your machine https://wiki.archlinux.org/index.php/Laptop/Lenovo
3. Use an Xorg.conf starting from there? https://github.com/MJaoune/ideapad330-config
4. make diagnosis of your input drivers like here (via Xorg.log) https://www.linuxquestions.org/quest...ad-4175624653/
5. use xserver-xorg-video-radeonhd? see there https://bugs.launchpad.net/ubuntu/+s...d/+bug/1829481
6.. look at results of googling "Lenovo Ideapad 330 linux xorg debian"..

feb11 · 03-06-2021, 09:53 AM

Quote:

Originally Posted by floppy_stuttgart

My thoughts..

Thanks, appreciate your input

Quote:

1. Update your BIOS?https://www.reddit.com/r/kernel/comm...s_ubuntu_1804/

Will be avoiding such drastic measures for now

Quote:

2. Arch looks ok for your machine https://wiki.archlinux.org/index.php/Laptop/Lenovo

I'm not using Arch, the laptop is set up dual boot Slackware and Debian (Slackware doesn't have this particular problem with touchpad btw, only Debian does)

Quote:

3. Use an Xorg.conf starting from there? https://github.com/MJaoune/ideapad330-config

At first glance, don't see any significant differences between my configs and theirs. 40-libinput.conf looks almost identical

Quote:

4. make diagnosis of your input drivers like here (via Xorg.log) https://www.linuxquestions.org/quest...ad-4175624653/

Switching the mode produces the following lines in the log:

Code:

[   614.748] (EE) AMDGPU(0): drmmode_do_crtc_dpms cannot get last vblank counter
[   614.748] (II) AMDGPU(0): Allocate new frame buffer 1024x768
[   614.749] (II) AMDGPU(0):  => pitch 4096 bytes

Changing brightness leaves no traces in the log

Quote:

5. use xserver-xorg-video-radeonhd? see there https://bugs.launchpad.net/ubuntu/+s...d/+bug/1829481

Doesn't look like the package is available:

Code:

apt install xserver-xorg-video-radeonhd
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package xserver-xorg-video-radeonhd

Quote:

6.. look at results of googling "Lenovo Ideapad 330 linux xorg debian"..

As obvious, that was the first thing I did before posting here. After reading some pages, the best idea I came up with was to upgrade the kernel to 4.19.15-041915-generic. I'll post the results here after I get my hands to it, at some point. I posted the question to see if there's a more straightforward way to solve the problem. The situation sucks, I haven't needed to upgrade kernels due to unsupported hardware for years and years. I'll return to this at some point. I'm running X server on another system so the laptop is used as headless system now, while I do productive work. Will have to return to this issue later, when in the summer I'll be travelling and will not have my desktop with me, to run the X on it.
Thanks

feb11 · 03-08-2021, 01:52 PM

Quote:

Switching the mode produces the following lines in the log:
[ 614.748] (EE) AMDGPU(0): drmmode_do_crtc_dpms cannot get last vblank counter

Searching for the above error message, found the following patch:

https://patchwork.freedesktop.org/patch/239365/

From: Michel Dänzer <michel.daenzer@amd.com>

We continued using the stale cached handle, causing issues e.g. when
resizing the screen via RandR.

Reported-by: iive on IRC
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

Code:

---
 src/radeon.h | 1 +
 1 file changed, 1 insertion(+)
Patch hide | download patch | download mbox
diff --git a/src/radeon.h b/src/radeon.h
index 450c69aa8..1a1edb1ba 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -735,6 +735,7 @@  static inline Bool radeon_set_pixmap_bo(PixmapPtr pPix, struct radeon_buffer *bo
 		    return TRUE;
 
 		radeon_buffer_unref(&priv->bo);
+		priv->handle_valid = FALSE;
 	    }
 
 	    drmmode_fb_reference(pRADEONEnt->fd, &priv->fb, NULL);

But I can't immediately figure which package the patch went into. Checked xserver-xorg-video-ati and xorg but they seem up to date:

Code:

 apt-cache policy  xserver-xorg-video-ati                       
xserver-xorg-video-ati:
  Installed: 1:19.0.1-1
  Candidate: 1:19.0.1-1
  Version table:
 *** 1:19.0.1-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

apt-cache policy  xorg                  
xorg:
  Installed: 1:7.7+19
  Candidate: 1:7.7+19
  Version table:
 *** 1:7.7+19 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

Surely having no knowledge about Debian packaging, I'm missing something here. Is there any package I need to update to make sure the patch is present in my xorg?

shruggy · 03-08-2021, 04:11 PM

The error message is from xserver-xorg-video-amdgpu. Another AMD driver is xserver-xorg-video-radeon, which gets installed automatically as a dependency of xserver-xorg-video-ati.

Bear in mind, the description of xserver-xorg-video-amdgpu explicitly lists Stoney as supported chipset, while that of xserver-xorg-video-radeon doesn't. Neither does its manual page. Here are hardware probes for this graphics card, they all seem to use the amdgpu driver.

You can see all of the video drivers with

Code:

apt-cache pkgnames xserver-xorg-video-|sort

Two binary packages, xserver-xorg-video-ati and xserver-xorg-video-radeon, are built from the same source package xserver-xorg-video-ati. The former is just a wrapper that loads the latter as a sub-driver.

The patch in question is included in the Debian package.

feb11 · 03-08-2021, 07:50 PM

Quote:

The patch in question is included in the Debian package.

Thanks for all the info. Since the patch is present, I'm gonna have to look for some other possible solution.

mrmazda · 03-11-2021, 01:40 PM

The patch apparently went into xf86-video-radeon upstream, which Debian renames xserver-xorg-video-radeon. It contains no mention of amdgpu. Stoney is third generation GCN, making xf86-video-amdgpu upstream, which Debian renames xserver-x11-video-amdgpu, the optimal DDX driver for OP's GPU. There's no good reason to have xserver-x11-video-ati (a meta-package) or xserver-x11-video-radeon installed (unless OP simply wishes to experiment to see what happens trying to use the Radeon driver designed for older technologies), and 2nd fiddle to the modesetting DDX (upstream default for most non-ancient GPUs), which is 2nd fiddle to AMD GPUs GCN and newer.

feb11 · 03-14-2021, 06:55 PM

Removing both xserver-xorg-video-radeon and xserver-xorg-video-ati didn't have any effect, right, because xserver-xorg-video-amdgpu is used. Removing xserver-xorg-video-amdgpu resulted in the following lines in the x-server log:

[ 1940.588] (II) LoadModule: "amdgpu"
[ 1940.588] (WW) Warning, couldn't open module amdgpu

and instead of lines containing AMDGPU(0) I now have lines containing modeset(0). xrandr is offering many more video modes now, but changing the mode results in the same problem as before: no clicks, no keyboard input anymore.

mrmazda · 03-15-2021, 12:52 AM

Modeset(0) is the default for all AMD, ATI, Intel and NVidia GPUs it supports, which is most for the past 15 years or so. Amdgpu is automatically used instead for AMD GPUs since somewhere around 2015 (Volcanic Islands, which Stoney is), if (on a Debian) package xserver-xorg-video-amdgpu is installed, and none of X is broken (IOW, working apparently normally).

I just tried on a desktop PC running Debian 10 and kernel 4.19.0-14 (aka 4.19.171-2) with my newest AMD, a Kaveri GPU roughly 2 years older than OP's Stoney, connected via DisplayPort.

Code:

# inxi -SGIay
System:
  Host: asa88 Kernel: 4.19.0-14-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
  parameters:...radeon.cik_support=0 amdgpu.cik_support=1 video=1440x900@60 3
  Desktop: Trinity R14.0.9 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: startx
  Distro: Debian GNU/Linux 10 (buster)
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu
  v: kernel alternate: radeon bus ID: 00:01.0 chip ID: 1002:130f
  class ID: 0300
  Display: server: X.Org 1.20.4 driver: loaded: amdgpu
  unloaded: fbdev,modesetting,vesa alternate: ati display ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 108 s-size: 451x282mm (17.8x11.1")
  s-diag: 532mm (20.9")
  Monitor-1: DisplayPort-0 res: 1920x1200 hz: 60 dpi: 94
  size: 519x324mm (20.4x12.8") diag: 612mm (24.1")
  OpenGL: renderer: AMD KAVERI (DRM 3.27.0 4.19.0-14-amd64 LLVM 7.0.1)
  v: 4.5 Mesa 18.3.6 direct render: Yes
Info:...Shell: Bash v: 5.0.3 running in: konsole  inxi: 3.3.01

Both the following commands similar to those from comment #1 produce only intended results:

Code:

xrandr --output DisplayPort-0 --brightness 0.35
xrandr --output DisplayPort-0 --mode 1680x1080

So do both of these:

Code:

xrandr --output DisplayPort-0 --mode 1680x1050 --brightness 0.5
xrandr --output DisplayPort-0 --mode 1440x900 --brightness 0.65

When "in X-window" in OP was written, what exactly was meant? Which DE (if any) is in use? Which WM is in use? Is the failure the same if an alternate WM and/or DE is used?

feb11 · 03-16-2021, 09:03 AM

Thanks for the info.

Quote:

Originally Posted by mrmazda

When "in X-window" in OP was written, what exactly was meant? Which DE (if any) is in use? Which WM is in use? Is the failure the same if an alternate WM and/or DE is used?

"In X-window" means what it says, I'm using the graphical environment known as X-window, as opposed to the text console. The window manager is fvwm if you think this information is relevant.

mrmazda · 03-16-2021, 02:58 PM

Quote:

Originally Posted by feb11

"In X-window" means what it says, I'm using the graphical environment known as X-window, as opposed to the text console. The window manager is fvwm if you think this information is relevant.

"X-window" is ambiguous. The X Window System typically goes by such monikers as "X", "XOrg", or "X windows", without any hyphens, and with an "s" after the second "w". "X-window" could be read to mean one of the many obscure WMs or DEs most never heard of.

Does it help to run either or both commands in a startup script?

Does it help if you combine your two commands into one as in my examples?

Does the problem persist if you use some other WM? (Possibly FVWM is broken and not your PC or installation.)

shruggy · 03-16-2021, 03:23 PM

Citing the Wikipedia article mrmazda linked to above:

Quote:

The proper names for the system are listed in the manual page as X; X Window System; X Version 11; X Window System, Version 11; or X11.

The term "X-Windows" (in the manner of the subsequently released "Microsoft Windows") is not officially endorsed – with X Consortium release manager Matt Landau stating in 1993, "There is no such thing as 'X Windows' or 'X Window', despite the repeated misuse of the forms by the trade rags" – though it has been in common informal use since early in the history of X and has been used deliberately for provocative effect, for example in the Unix-Haters Handbook.

X-LFS-2010 · 03-16-2021, 09:05 PM

"X-window" is ambiguous. WRONG.

it means Xeros windows as in the Xerox Copy company (it can be found on wikipedia, the original NETWORK TRANSPARENT WINDOW SYSTEM)

Other "robbers of X" are done for "product confusion", like "X box" which is totally un-affiliated with Xeros code base, Microsoft CITRIX robbed remote X (they deleted the app that opens remote X clients from Xorg - then try to sell people the same feature - while lying abou the fact X can open remote apps anyway: it's already nework transparent). Product confusion labeling is illegal in the USA, though it may not be in your country.

Xorg is not X11, it's X12, they did some hacks i'd like to whack them for - killing compatibility with X11 and X10 for ... political take-over reasons will be my un-argued argument.

------------------------------

please don't get me started with politics

------------------------------

I didn't read all of the above. I lost keyboard mouse recently loading Xorg. It turned out the "X --configure" or someone had put something in xorg.conf that was NOT NECESSARY. Try removing anything un-necessary in your xorg.conf - see if you don't get a mouse and keyboard.

Bye the way - if your video driver isn't going to load X might unload the mouse and keyboard before it exits and show a log of doing so. Make sure in your Xorg.log that it says X had a video configuration it believed would work. Make sure you "specify nothing you don't have to" on your first attempts. Use "vesa" driver to start with. "twm" as your window manager like: "X & sleep 1 ; twm &" so you know it's not your WM taking the whole thing down.

X-LFS-2010 · 03-16-2021, 09:06 PM

in other words - i had the same messages in my log believed i had input problems ...

turned out i had a very simple problem in xorg.conf and no input problems

mrmazda · 03-16-2021, 09:57 PM

Quote:

Originally Posted by X-LFS-2010

I didn't read all of the above. I lost keyboard mouse recently loading Xorg. It turned out the "X --configure" or someone had put something in xorg.conf that was NOT NECESSARY. Try removing anything un-necessary in your xorg.conf - see if you don't get a mouse and keyboard.

The way forward for xorg.conf in current editions of Xorg is for starting with no xorg.conf at all. Xorg automatic configuration works beautifully for the vast majority of pure FOSS users, specifically to the exclusion of proprietary (non-FOSS) NVidia GPU driver users.

X --configure is an anachronism, generating a clutter of un-necessaries to obfuscate need for anything that might actually be required, if it doesn't simply crash.

Is *libinput* installed? Most current distros include it automatically, in lieu of specific keyboard, mouse, tablet or other input device handlers.