| Author |
Message |
alexk
|
|
|
Post subject: xserver-xorg-input* packages to be removed
 Posted: 27.01.2016, 15:15
|
|
Joined: 2010-10-01
Posts: 288
Status: Offline
|
|
| If one tries to upgrade xserver-xorg-core to the latest version 2:1.18.0-2 in Sid, one ends up without input ability in X (no keyboard/mouse) because all xserver-xorg-input* packages get removed, because of a missing dependency on virtual package xorg-input-abi-21. I was brazen/foolish enough to try this. My system is operational again by downgrading to the testing version of xserver-xorg-core (2:1.17.3-2) and reinstalling the required xserver-xorg-input packages. |
Last edited by alexk on 29.01.2016, 02:45; edited 1 time in total
|
| |
|
|
|
 |
|
karoheinzi
|
|
|
Post subject: RE: xserver-xorg-input* packages to be removed
Posted: 27.01.2016, 23:04
|
|
Joined: 2016-01-27
Posts: 2
Location: DE
Status: Offline
|
|
Thanks, alexk, for the hints what happened and why.
Here's a workaround how to get back to old state for anyone who managed to find the same trap as successful as me, just by making dist-upgrade... 
- reboot your machine by editing the grub command line and adding "init 3" at the end of the linux kernel line, so the system boots with runlevel 3, network on, keyboard on, xserver off
- login with root
- locate your debian.list file, mine was under
/etc/apt/sources.list.d/debian.list
- copy the line with the word UNSTABLE, put a # in front of this line to set the comment and replace UNSTABLE with TESTING (no need for capital letters) in the new line - for example (see also aptosid-manual):
deb http://ftp.nl.debian.org/debian/ testing main contrib non-free
and save the .list file
- remove packet xserver-xorg-core with
apt-get update
and
apt-get remove xserver-xorg-core
- install the previous core module from "testing" branch with
apt-get install xserver-xorg-core/testing
- install the input device drivers with
apt-get install xserver-xorg-input-all/testing
(or only the specific ones if you care)
- set the two or more packets on hold using the command as described in aptosid-manual (--> http://manual.aptosid.com/en/sys-admin- ... -downgrade )
echo package hold|dpkg --set-selections
- reboot
- test input devices, no warranties given, as usual, community free to add/correct/comment. |
|
|
| |
|
|
|
|
|
i686
|
|
|
Post subject: RE: xserver-xorg-input* packages to be removed
Posted: 28.01.2016, 00:07
|
|
Joined: 2010-11-06
Posts: 3
Status: Offline
|
|
| Thank you both for finding and giving details how to fix this. The above worked great for me, except I had to use "init 1", since "init 3" was being ignored on my system. |
|
|
| |
|
|
|
|
|
alexk
|
|
|
Post subject: RE: xserver-xorg-input* packages to be removed
Posted: 28.01.2016, 01:14
|
|
Joined: 2010-10-01
Posts: 288
Status: Offline
|
|
The issue looks mostly solved now, with only xserver-xorg-input-evdev currently to be removed.
I was able to boot into init 3 by just adding "3" to the kernel line. |
|
|
| |
|
|
|
|
|
finotti
|
|
|
Post subject: RE: xserver-xorg-input* packages to be removed
Posted: 29.01.2016, 22:11
|
|
Joined: 2010-09-12
Posts: 493
Status: Offline
|
|
| I have xserver-xorg-video-openchrome and xserver-xorg-video-siliconmotion marked for removal in all my systems. Are they OK to let go? |
|
|
| |
|
|
|
|
|
slh
|
|
|
Post subject: Re: RE: xserver-xorg-input* packages to be removed
Posted: 29.01.2016, 23:01
|
|
Joined: 2010-08-25
Posts: 962
Status: Offline
|
|
|
finotti wrote:
I have xserver-xorg-video-openchrome and xserver-xorg-video-siliconmotion marked for removal in all my systems. Are they OK to let go?
Yes, unless you have the according graphics hardware (very unlikely, you'd probably knew if you had it).
Support for ancient/ rare graphics card is slowly being dropped from X.org - or at least there is little interest in distributions to keep it compiling against modern/ evolving X.org versions without even being able to test for the success of this kind of porting. The particular hardware you're mentioning was already obsolete 10 years ago and rare/ old/ bad 15 years ago.
A lot is happening around X.org (X, wayland, freedesktop, mesa, etc.), development doesn't halt there - and each hardware driver needs some minimal amount of maintenance, which is vanishing for the really old devices. As a result distributions slowly start dropping the rarer/ barely maintained drivers from the everything-and-the-kitchen-sink metapackages (xserver-xorg-input-all, xserver-xorg-video-all) - to avoid lagging maintenance for these ancient devices to affect more mainstream users (== not to risk users getting their meta-packages removed by accident, just because some ancient driver isn't ready yet). Depending on the maintenance situation, support for some of these older drivers is at risk and about to be dropped for good.
If you look at X.org maintenance, the mainstream graphics are safe and under active development (both keeping older devices supported and improving the situation for new hardware):
- intel
- nouveau (nvidia hardware)
- radeon (AMD/ ATi hardware)
- virtual graphics (modesetting (qemu-kvm), qxl (qemu-kvm), virgl (qemu-kvm), vmware, etc.)
- to a much lesser extent mga (matrox hardware, often found on server mainboards)
- some FOSS development for ARM devices (etnaviv, videocore/ vc4)
All of these drivers have active developer bases behind them and made the switch to the KMS (kernel based modesetting) driver model long time ago, which is a prerequisite for wayland and rootless X.org.
Older hardware requiring any of the special X.org drivers (cirrus, neomagic, tdfx, trident, openchrome, siliconmotion, sis, etc.) is on extended life support and always at risk to be abandoned for good - e.g. unless some miracle code fairies come along, neither of those will make the jump towards wayland (if they even survive that long). To some extent, VESA/ fbdev keep this hardware still supported at a minimal level, usually at the cost of not supporting non-VESA resolutions (the drivers in question typically don't support anything fancy beyond this, so the vesa driver isn't that much of a regression in terms of performance). |
|
|
| |
|
|
|
|
|
|
