FFe: xserver 1.19.3

Bug #1671799 reported by Timo Aaltonen on 2017-03-10
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Undecided
Timo Aaltonen

Bug Description

xserver 1.19 has been out for quite some time now. Debian Stretch will release with it, and xmir has been recently ported so we can push 1.19 to zesty now. It's currently being staged on a ppa:

https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging

The main features of this release are:
- PRIME synchronization support, should reduce tearing on hybrid setups
- GLAMOR (2D accel over OpenGL) improvements
- threaded input

This bugreport is also for gathering testing feedback.

Tested to be working fine on:
- Intel Kabylake
- Intel Broadwell
- Intel+NVIDIA hybrid (Skylake + 930MX, with OSS and blob drivers)
- Intel+NVIDIA hybrid (Haswell + NVIDIA GK107M [GeForce GT 755M])
- Intel+NVIDIA hybrid (Ivybridge + NVIDIA GK107M [GeForce GT 660M])
- Radeon SI (radeon & amdgpu drivers)
- qemu (QXL)

dino99 (9d9) wrote :

Feedback on ZZ 64 bits, unity 7 session, nv117 (gtx750) card , after mesa/xserver upgrades

- upgrade goes well (wine-devel removed due to libglu dependency)
- after reboot: numpad is deactivated and cant be activated at login level; after the session is opened, numlock is on and cant be set off.
- journalctl is fine, except that compiz has many warnings/errors (log joined to let you know, but it seems a compiz needed upgrade to be happy with mesa/xserver)

iLogin (cerebellum-l) wrote :

also stopped working Caps Lock... when press the Caps Lock, most combinations not working at all.

dino99 (9d9) wrote :

Also problem scrolling with chromium-browser and calc: does not work.
If caps-lock status is not modified by the user, then the keyboard can be used as expected; otherwise, keyboard's language is lost and typing is a nightmare: no arrows, no erase back, ...

dino99 (9d9) wrote :

If xserver is downgraded to the previous 1.18.4 version, and rebooted, then there is no warning/error logged about compiz.

iLogin (cerebellum-l) wrote :

you may need to update this patch?
208_switch_on_release.diff
https://bugs.freedesktop.org/show_bug.cgi?id=865#c142

iLogin (cerebellum-l) wrote :

Without this patch my keyboard works.

Timo Aaltonen (tjaalton) wrote :

Thanks for testing! Indeed, I had not tested it properly, since I could reproduce the bug.. Dropped the patch and pushed to the ppa, now caps-lock etc works fine

dino99 (9d9) wrote :

Now its fine here too with 1.19.2-1ubuntu2 version:
- no more keyboard issue
- no more scrolling issue
- no more compiz issue

Thanks for the quick upgrade.

Doug McMahon (mc3man) wrote :

Here with fresh 17.04 Ubuntu install using today's image -
After adding ppa & upgrading a reboot goes to low graphics screen.
This is on a Lenovo IdeaPad Y510P, nvidia drivers not installed.
Logs seem unremarkable, only way to boot to ubuntu session is thru recovery (nomodeset

Doug McMahon (mc3man) wrote :

Same thing with a lenovo IdeaPad Y580 (sandybridge) except there it doesn't even make it the low graphic pop up.

In both cases (sandybridge & previous laptop which is haswell) if I install the nvidia drivers & reboot, it does boot up to an ubuntu session. From there switching via prime profiles to intel gpu works & survives a reboot.
So the issue is on an upgrade of xserver while on the Intel iGPU, maybe how alternatives are set?

Also to report that when the nvidia drivers are used via nvidia-prime the current lack of any vsync is Not solved at all.. ( logs look good for prime synchronization, just doesn't work.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xorg-server (Ubuntu):
status: New → Confirmed

Tested on Lenovo Yoga 20FY that has an Optimus setup (Intel HD 520 and Nvidia 540M Card).
Used Ubuntu 17.04 daily and added PPA: https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging.

Test 1 - No restricted/closed drivers
Upgrade worked with no packages broken, etc.. Unfortunately, Ubuntu will not boot after doing this and just hangs forever.

Test 2 - Enable restricted/closed NVidia driver (and Intel microcode if it matters) BEFORE PPA
Upgrade worked with no packages broken, etc.. Ubuntu was able to boot and I was able to login. There didn't seem to be any obvious problems with the graphics stack at this point.

Timo Aaltonen (tjaalton) wrote :

Hangs how? This stack has been in debian for some time now, so I believe it's your hybrid configuration that is somehow busted.

Doug McMahon (mc3man) wrote :

Pretty simple here -
Will only successfully boot to greeter, ect. when nvidia drivers are installed.
If the drivers aren't installed then it either 'hangs' right after the fs check on sandybridge or goes to low graphics pop up on haswell.

Once the nvidia drivers are installed then boot ups work fine whether using either nvidia or intel. (as picked thru prime profiles or prime-select.

If the nvidia drivers are removed then again boot up fails so something is certainly amiss on your or Ubuntu's end.

dino99 (9d9) wrote :
Timo Aaltonen (tjaalton) wrote :

I can repro that bug! Related to offload gpu autobinding..

Timo Aaltonen (tjaalton) wrote :

1.19.3-1u0.1 uploaded, please test

On 03/16/2017 07:20 AM, Timo Aaltonen wrote:
> 1.19.3-1u0.1 uploaded, please test
>
Does indeed resolve issue when nvidia drivers are not installed.

(out of the scope of this FFe, many optimus users will be expecting
prime synchronization to work. At least here it doesn't when using
nvidia drivers via nvidia-prime.

Is this worth a new bug once 1.19.x releases to 17.04?

Timo Aaltonen (tjaalton) on 2017-03-16
description: updated

Have upgraded and made a reboot: works fine and log clean too on the system described previously.

On 16.03.2017 14:04, Doug McMahon wrote:
> On 03/16/2017 07:20 AM, Timo Aaltonen wrote:
>> 1.19.3-1u0.1 uploaded, please test
>>
> Does indeed resolve issue when nvidia drivers are not installed.

Yes, I've verified it myself.

> (out of the scope of this FFe, many optimus users will be expecting
> prime synchronization to work. At least here it doesn't when using
> nvidia drivers via nvidia-prime.
>
> Is this worth a new bug once 1.19.x releases to 17.04?

I heard that it was discussed on the nvidia forums to be due to 4.10
kernel, so yes a new bug would be in order.

Timo Aaltonen (tjaalton) on 2017-03-16
description: updated
Timo Aaltonen (tjaalton) on 2017-03-16
Changed in xorg-server (Ubuntu):
assignee: nobody → Timo Aaltonen (tjaalton)

Seems ok on both
Intel+NVIDIA hybrid Haswell + NVIDIA GK107M [GeForce GT 755M]
Intel+NVIDIA hybrid Ivybridge + NVIDIA GK107M [GeForce GT 660M]

Though both show an oddity in inxi reporting when on Intel with nvidia drivers not installed -
Ex.,
intel xserver not installed, no nvidia drivers installed, with the apparent Ubuntu default of DRI2 only

$ inxi -G
Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GT 755M]
           Display Server: X.Org 1.19.3 drivers: (unloaded: fbdev,vesa) FAILED: modesetting,nouveau
           Resolution: 1920x1080@59.91hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 17.0.1

The same is reported if intel xserver package is installed.

If nvidia drivers are installed -

intel xserver not installed, nvidia installed, DRI2
$ inxi -G
Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GT 755M]
           Display Server: X.Org 1.19.3 drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@59.91hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 17.0.1
inxi -G
Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GT 755M]
           Display Server: X.Org 1.19.3 drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@59.91hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 17.0.1

The same is reported if intel xserver package is installed.

If I was to enable DRI3 then more expected? reporting, doesn't matter if nvidia drivers are installed or not.

intel xserver installed, DRI3
$ inxi -G
Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GT 755M]
           Display Server: X.Org 1.19.3 driver: intel
           Resolution: 1920x1080@59.91hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 17.0.1

no intel xserver, DRI3
$ inxi -G
Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GT 755M]
           Display Server: X.Org 1.19.3 drivers: modesetting,nouveau (unloaded: fbdev,vesa)
           Resolution: 1920x1080@59.91hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 17.0.1

Timo Aaltonen (tjaalton) wrote :

sounds like an inxi bug then.. note that modesetting uses DRI3 by default

Timo Aaltonen (tjaalton) on 2017-03-17
description: updated
summary: - FFe: xserver 1.19.x
+ FFe: xserver 1.19.3
dino99 (9d9) wrote :

Problem found:

its about using mouse: selecting columns & raws with libreoffice calc.

results are erratic:
- sometime that works as expected (less than half time)
- most of the time when you first click on a cell then move the mouse to the other cell at the end of the wanted selection, here start the erratic results: either lost the already selected cells before the selection is completed done, or start moving the first part of the selection, or if all the selection can be done and you release the mouse click, then either you completly lost the selection or only a part of that selection is still active.

Well its fully not usable; this have been met with several opened gnome-shell sessions from the past days.

To compare, on the same machine but with a zz partition which still use the xserver 1.18 version (fully updated genuine zz) and the same spreadsheet:
- doing a cells selection always works as expected
- the selection is never lost/moved/...
- doing the selection let a better feeling of mouse fluidity.

So something still need to be investigated about how the mouse works. (seems a sensitivity issue)

Timo Aaltonen (tjaalton) wrote :

assuming you're using the -libinput driver; please build the ppa version (0.25.0) on zesty or the zesty version against 1.19 and try again

dino99 (9d9) wrote :

Thanks for the answer

i have libinput10 & bin 1.6.3-1ubuntu1 installed like all ZZ default installs.
I'm not sure what exactly doing to have compatible version installed.
So i propose to wait until this recompilation is done by default on ZZ archive

dino99 (9d9) wrote :

note: the package xserver-xorg-input-libinput 0.23.0-2 is not installed; does it should ?

as the meta package (input-all) is also not installed, the above one has not been requested by an other one.
So i install it, and will test it tomorrow; will report here in the coming 12 hours or so to let you know about the possible result change.

Timo Aaltonen (tjaalton) wrote :

By mouse do you mean touchpad or an actual mouse? Touchpads use -synaptics which got bumped to 1.9.0. Test a real mouse too if not already.

Timo Aaltonen (tjaalton) wrote :

fwiw, I can't repro that bug on a touchpad using -libinput (synaptics doesn't work right with it)

dino99 (9d9) wrote :

Made some tests, with both xserver 18 & with/without input-libinput 23 ; and xserver 19 with/without input-libinput 25

To clarify 'mouse': it's a generic usb mouse, no touchpad at all. Tests made on two different ZZ partitions on the same desktop.

Test xserver 18
- note that comment #26 above is a bit confusing: i was talking about the partition using xserver 18
- xserver 18 without input-libinput 23: works well (as previouly said (#23)
- xserver 18 + input-libinput 23: no problem to select a range of calc's cells; but discovered an other 'scrolling' issue when trying to set the 'sort criteria' for keys: scrolling does not work.
That is when using Calc sorting; testing 'scrolling' inside 'nautilus' works well (confusing).
So i purge input-libinput hoping to get back a normal calc's sorting scrolling; that fails; closing calc / restating gnome-shell session / even logout/in the session does not set scrolling back (confusion again); Check System settings mouse options /gnome-tweak-tool but settings are as usual.

- xserver 19 + input-libinput 25 : problem initialy reported
- xserver 19 without input-libinput 25 (23 not installable due to abi, so cant test that case): selecting a cells range can be done as expected, scrolling for sorting also works !!!

dino99 (9d9) wrote :

This scrolling issue has been met also outside the ubuntu world:
https://ubuntuforums.org/showthread.php?t=2355713&p=13622468#post13622468

Timo Aaltonen (tjaalton) wrote :

-libinput has been the default since 16.10 where it replaced -evdev (-input-all pulls -libinput), so I don't consider this a blocker, since it doesn't seem to be a widespread issue (I can't reproduce it with a mouse either). Feel free to file a bug against -libinput, upstream too if you can.

Timo Aaltonen (tjaalton) on 2017-03-20
description: updated
Doug McMahon (mc3man) wrote :

Ot to FFe
Bug filed regarding PRIME synchronization with hybrid hardware implemented via nvidia-prime
Bug 1674304

Dave Morley (davmor2) wrote :

Tested this on several machines
Intel, trackpad, keybaord, touchscreen, 4k on xps13
Amd, usb keyboard/mouse, 1080p on Home built all amd box
Nvidia, ps2 keybaord/mouse, 1080p on home built mixed box

Dave Morley (davmor2) wrote :

All tests on zesty plus ppa

Dave Morley (davmor2) wrote :

No issues discovered

Iain Lane (laney) wrote :

I'm really worried about doing this so late.

But if you're willing to take the risk, if you will keep a close eye on incoming bug reports & errors.ubuntu.com and if you will upload very soon, go ahead.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.