2018-05-21 19:54:15

by Vito Caputo

[permalink] [raw]
Subject: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

Hello all,

4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
without -window. I will try find time to build the latest rc this
evening.

> ~$ xgalaga
> X Error of failed request: BadValue (integer parameter out of range for operation)
> Major opcode of failed request: 152 (XFree86-VidModeExtension)
> Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> Value in failed request: 0x120004e
> Serial number of failed request: 199
> Current serial number in output stream: 203

Haven't dug into this much yet, only did a perfunctory check by booting into a
few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
It appears to be a 4.17-specific regression right now.

Also observed, though this is surely a different regression, the game
ran like molasses with -window, showing some prominent kworkers in top:

692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss

The windowed performance issue was observed on the older kernels tested
as well, though 4.11 felt better and didn't have the busy kworkers.

I have not attempted to play xgalaga for ages, but it used to be perfectly
playable on this machine in windowed mode when I last did.

Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.

Regards,
Vito Caputo


Attachments:
(No filename) (1.84 kB)
4.17-rc4-config.gz (23.89 kB)
Download all attachments

2018-05-21 21:57:59

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> Hello all,
>
> 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> without -window. I will try find time to build the latest rc this
> evening.
>
> > ~$ xgalaga
> > X Error of failed request: BadValue (integer parameter out of range for operation)
> > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > Value in failed request: 0x120004e
> > Serial number of failed request: 199
> > Current serial number in output stream: 203
>
> Haven't dug into this much yet, only did a perfunctory check by booting into a
> few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> It appears to be a 4.17-specific regression right now.
>
> Also observed, though this is surely a different regression, the game
> ran like molasses with -window, showing some prominent kworkers in top:
>
> 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
>
> The windowed performance issue was observed on the older kernels tested
> as well, though 4.11 felt better and didn't have the busy kworkers.
>
> I have not attempted to play xgalaga for ages, but it used to be perfectly
> playable on this machine in windowed mode when I last did.
>
> Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
>

Just built and booted v4.17-rc6, still broken.

2018-05-23 09:49:49

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > Hello all,
> >
> > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > without -window. I will try find time to build the latest rc this
> > evening.
> >
> > > ~$ xgalaga
> > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > Value in failed request: 0x120004e
> > > Serial number of failed request: 199
> > > Current serial number in output stream: 203
> >
> > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > It appears to be a 4.17-specific regression right now.
> >
> > Also observed, though this is surely a different regression, the game
> > ran like molasses with -window, showing some prominent kworkers in top:
> >
> > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> >
> > The windowed performance issue was observed on the older kernels tested
> > as well, though 4.11 felt better and didn't have the busy kworkers.
> >
> > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > playable on this machine in windowed mode when I last did.
> >
> > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> >
>
> Just built and booted v4.17-rc6, still broken.

Bisected to:

e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
commit e995ca0b8139c5f6807095464e969931b443f55a
Author: Ville Syrj?l? <[email protected]>
Date: Tue Nov 14 20:32:58 2017 +0200

drm/i915: Provide a device level .mode_valid() hook

We never support certain mode flags etc. Reject those early on in the
mode_config.mode_valid() hook. That allows us to remove some duplicated
checks from the connector .mode_valid() hooks, and it guarantees that
we never see those flags even from user mode as the
mode_config.mode_valid() hooks gets executed for those as well.

Signed-off-by: Ville Syrj?l? <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>

Will CC Ville and Daniel.

Regards,
Vito Caputo

2018-05-23 13:20:10

by Ville Syrjälä

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > Hello all,
> > >
> > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > without -window. I will try find time to build the latest rc this
> > > evening.
> > >
> > > > ~$ xgalaga
> > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > Value in failed request: 0x120004e
> > > > Serial number of failed request: 199
> > > > Current serial number in output stream: 203
> > >
> > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > It appears to be a 4.17-specific regression right now.
> > >
> > > Also observed, though this is surely a different regression, the game
> > > ran like molasses with -window, showing some prominent kworkers in top:
> > >
> > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > >
> > > The windowed performance issue was observed on the older kernels tested
> > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > >
> > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > playable on this machine in windowed mode when I last did.
> > >
> > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > >
> >
> > Just built and booted v4.17-rc6, still broken.
>
> Bisected to:
>
> e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> commit e995ca0b8139c5f6807095464e969931b443f55a
> Author: Ville Syrj?l? <[email protected]>
> Date: Tue Nov 14 20:32:58 2017 +0200
>
> drm/i915: Provide a device level .mode_valid() hook
>
> We never support certain mode flags etc. Reject those early on in the
> mode_config.mode_valid() hook. That allows us to remove some duplicated
> checks from the connector .mode_valid() hooks, and it guarantees that
> we never see those flags even from user mode as the
> mode_config.mode_valid() hooks gets executed for those as well.
>
> Signed-off-by: Ville Syrj?l? <[email protected]>
> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> Reviewed-by: Daniel Vetter <[email protected]>

Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
the ddx doesn't validate before passing it on to the kernel. So far
I can't reproduce the problem here unfortnately.

Can you try the following patch and reproduce the problem with
drm.debug=0xe passed to the kernel so that we can seewhat the bad
modeline looks like?

From c8b4eaaf3ee8e796dbbb4a5080c1aec2b435d110 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <[email protected]>
Date: Wed, 23 May 2018 16:12:08 +0300
Subject: [PATCH] drm/modes: Dump the rejected user mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Print put the modeline When we reject a user mode.

Cc: Vito Caputo <[email protected]>
Signed-off-by: Ville Syrj?l? <[email protected]>
---
drivers/gpu/drm/drm_modes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c78ca0e84ffd..ca50b12d9701 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1739,8 +1739,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
}

out->status = drm_mode_validate_driver(dev, out);
- if (out->status != MODE_OK)
+ if (out->status != MODE_OK) {
+ DRM_DEBUG_KMS("Bad user mode:\n");
+ drm_mode_debug_printmodeline(out);
return -EINVAL;
+ }

drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);

--
2.16.1

--
Ville Syrj?l?
Intel

2018-05-23 18:07:15

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > Hello all,
> > > >
> > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > without -window. I will try find time to build the latest rc this
> > > > evening.
> > > >
> > > > > ~$ xgalaga
> > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > Value in failed request: 0x120004e
> > > > > Serial number of failed request: 199
> > > > > Current serial number in output stream: 203
> > > >
> > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > It appears to be a 4.17-specific regression right now.
> > > >
> > > > Also observed, though this is surely a different regression, the game
> > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > >
> > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > >
> > > > The windowed performance issue was observed on the older kernels tested
> > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > >
> > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > playable on this machine in windowed mode when I last did.
> > > >
> > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > >
> > >
> > > Just built and booted v4.17-rc6, still broken.
> >
> > Bisected to:
> >
> > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > commit e995ca0b8139c5f6807095464e969931b443f55a
> > Author: Ville Syrj?l? <[email protected]>
> > Date: Tue Nov 14 20:32:58 2017 +0200
> >
> > drm/i915: Provide a device level .mode_valid() hook
> >
> > We never support certain mode flags etc. Reject those early on in the
> > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > checks from the connector .mode_valid() hooks, and it guarantees that
> > we never see those flags even from user mode as the
> > mode_config.mode_valid() hooks gets executed for those as well.
> >
> > Signed-off-by: Ville Syrj?l? <[email protected]>
> > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > Reviewed-by: Daniel Vetter <[email protected]>
>
> Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> the ddx doesn't validate before passing it on to the kernel. So far
> I can't reproduce the problem here unfortnately.
>
> Can you try the following patch and reproduce the problem with
> drm.debug=0xe passed to the kernel so that we can seewhat the bad
> modeline looks like?
>

dmesg after xgalaga fails:

```
[ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
[ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
[ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
```

xrandr --verbose:

```
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
Identifier: 0x41
Timestamp: 23375
Subpixel: horizontal rgb
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 0
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff0030ae004000000000
3010010380191278eafe609555518726
22505421080001010101010101010101
01010101010128150040410026301888
3600f6b800000018ed10004041002630
18883600f6b9000000180000000f0061
43326143280f01000daf0714000000fe
004e31323158352d4c303620202000ed
scaling mode: Full aspect
supported: Full, Center, Full aspect
non-desktop: 0
range: (0, 1)
link-status: Good
supported: Good, Bad
1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
v: height 768 start 771 end 777 total 806 clock 50.00Hz
1024x768 (0x45) 65.000MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
v: height 768 start 771 end 777 total 806 clock 60.00Hz
1024x768 (0x46) 43.330MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
v: height 768 start 771 end 777 total 806 clock 40.00Hz
960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
v: height 720 start 720 end 722 total 750 clock 60.00Hz
928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
v: height 696 start 696 end 698 total 719 clock 60.05Hz
896x672 (0x49) 102.400MHz -HSync +VSync DoubleScan
h: width 896 start 960 end 1060 total 1224 skew 0 clock 83.66KHz
v: height 672 start 672 end 674 total 697 clock 60.01Hz
960x600 (0x4a) 77.000MHz +HSync -VSync DoubleScan
h: width 960 start 984 end 1000 total 1040 skew 0 clock 74.04KHz
v: height 600 start 601 end 604 total 617 clock 60.00Hz
960x540 (0x4b) 69.250MHz +HSync -VSync DoubleScan
h: width 960 start 984 end 1000 total 1040 skew 0 clock 66.59KHz
v: height 540 start 541 end 544 total 555 clock 59.99Hz
800x600 (0x4c) 81.000MHz +HSync +VSync DoubleScan
h: width 800 start 832 end 928 total 1080 skew 0 clock 75.00KHz
v: height 600 start 600 end 602 total 625 clock 60.00Hz
800x600 (0x4d) 40.000MHz +HSync +VSync
h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz
v: height 600 start 601 end 605 total 628 clock 60.32Hz
800x600 (0x4e) 36.000MHz +HSync +VSync
h: width 800 start 824 end 896 total 1024 skew 0 clock 35.16KHz
v: height 600 start 601 end 603 total 625 clock 56.25Hz
840x525 (0x4f) 73.125MHz -HSync +VSync DoubleScan
h: width 840 start 892 end 980 total 1120 skew 0 clock 65.29KHz
v: height 525 start 526 end 529 total 544 clock 60.01Hz
840x525 (0x50) 59.500MHz +HSync -VSync DoubleScan
h: width 840 start 864 end 880 total 920 skew 0 clock 64.67KHz
v: height 525 start 526 end 529 total 540 clock 59.88Hz
800x512 (0x51) 51.562MHz +HSync +VSync DoubleScan
h: width 800 start 800 end 828 total 832 skew 0 clock 61.97KHz
v: height 512 start 512 end 514 total 515 clock 60.17Hz
700x525 (0x52) 61.000MHz +HSync +VSync DoubleScan
h: width 700 start 744 end 820 total 940 skew 0 clock 64.89KHz
v: height 525 start 526 end 532 total 541 clock 59.98Hz
640x512 (0x53) 54.000MHz +HSync +VSync DoubleScan
h: width 640 start 664 end 720 total 844 skew 0 clock 63.98KHz
v: height 512 start 512 end 514 total 533 clock 60.02Hz
720x450 (0x54) 53.250MHz -HSync +VSync DoubleScan
h: width 720 start 760 end 836 total 952 skew 0 clock 55.93KHz
v: height 450 start 451 end 454 total 467 clock 59.89Hz
640x480 (0x55) 54.000MHz +HSync +VSync DoubleScan
h: width 640 start 688 end 744 total 900 skew 0 clock 60.00KHz
v: height 480 start 480 end 482 total 500 clock 60.00Hz
640x480 (0x56) 25.175MHz -HSync -VSync
h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz
v: height 480 start 490 end 492 total 525 clock 59.94Hz
680x384 (0x57) 42.375MHz -HSync +VSync DoubleScan
h: width 680 start 716 end 784 total 888 skew 0 clock 47.72KHz
v: height 384 start 385 end 390 total 399 clock 59.80Hz
680x384 (0x58) 36.000MHz +HSync -VSync DoubleScan
h: width 680 start 704 end 720 total 760 skew 0 clock 47.37KHz
v: height 384 start 385 end 390 total 395 clock 59.96Hz
576x432 (0x59) 40.810MHz -HSync +VSync DoubleScan
h: width 576 start 608 end 668 total 760 skew 0 clock 53.70KHz
v: height 432 start 432 end 434 total 447 clock 60.06Hz
512x384 (0x5a) 32.500MHz -HSync -VSync DoubleScan
h: width 512 start 524 end 592 total 672 skew 0 clock 48.36KHz
v: height 384 start 385 end 388 total 403 clock 60.00Hz
400x300 (0x5b) 20.000MHz +HSync +VSync DoubleScan
h: width 400 start 420 end 484 total 528 skew 0 clock 37.88KHz
v: height 300 start 300 end 302 total 314 clock 60.32Hz
400x300 (0x5c) 18.000MHz +HSync +VSync DoubleScan
h: width 400 start 412 end 448 total 512 skew 0 clock 35.16KHz
v: height 300 start 300 end 301 total 312 clock 56.34Hz
320x240 (0x5d) 12.587MHz -HSync -VSync DoubleScan
h: width 320 start 328 end 376 total 400 skew 0 clock 31.47KHz
v: height 240 start 245 end 246 total 262 clock 60.05Hz
VGA-1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp: 23375
Subpixel: unknown
Clones:
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
non-desktop: 0
range: (0, 1)
link-status: Good
supported: Good, Bad
```

I took a quick glance at the xgalaga source, and it looks to supply
XF86VidModeSwitchToMode() with an unmodified XF86VidModeModeInfo chosen from
the array returned by XF86VidModeGetAllModeLines().

Thanks,
Vito Caputo

2018-05-23 18:21:46

by Ville Syrjälä

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > Hello all,
> > > > >
> > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > without -window. I will try find time to build the latest rc this
> > > > > evening.
> > > > >
> > > > > > ~$ xgalaga
> > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > Value in failed request: 0x120004e
> > > > > > Serial number of failed request: 199
> > > > > > Current serial number in output stream: 203
> > > > >
> > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > It appears to be a 4.17-specific regression right now.
> > > > >
> > > > > Also observed, though this is surely a different regression, the game
> > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > >
> > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > >
> > > > > The windowed performance issue was observed on the older kernels tested
> > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > >
> > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > playable on this machine in windowed mode when I last did.
> > > > >
> > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > >
> > > >
> > > > Just built and booted v4.17-rc6, still broken.
> > >
> > > Bisected to:
> > >
> > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > Author: Ville Syrj?l? <[email protected]>
> > > Date: Tue Nov 14 20:32:58 2017 +0200
> > >
> > > drm/i915: Provide a device level .mode_valid() hook
> > >
> > > We never support certain mode flags etc. Reject those early on in the
> > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > we never see those flags even from user mode as the
> > > mode_config.mode_valid() hooks gets executed for those as well.
> > >
> > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > Reviewed-by: Daniel Vetter <[email protected]>
> >
> > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > the ddx doesn't validate before passing it on to the kernel. So far
> > I can't reproduce the problem here unfortnately.
> >
> > Can you try the following patch and reproduce the problem with
> > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > modeline looks like?
> >
>
> dmesg after xgalaga fails:
>
> ```
> [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25

0x20 == dblscan

> [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> ```
>
> xrandr --verbose:
>
> ```
> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> Identifier: 0x41
> Timestamp: 23375
> Subpixel: horizontal rgb
> Gamma: 1.0:1.0:1.0
> Brightness: 1.0
> Clones:
> CRTC: 0
> CRTCs: 0 1
> Transform: 1.000000 0.000000 0.000000
> 0.000000 1.000000 0.000000
> 0.000000 0.000000 1.000000
> filter:
> EDID:
> 00ffffffffffff0030ae004000000000
> 3010010380191278eafe609555518726
> 22505421080001010101010101010101
> 01010101010128150040410026301888
> 3600f6b800000018ed10004041002630
> 18883600f6b9000000180000000f0061
> 43326143280f01000daf0714000000fe
> 004e31323158352d4c303620202000ed
> scaling mode: Full aspect
> supported: Full, Center, Full aspect
> non-desktop: 0
> range: (0, 1)
> link-status: Good
> supported: Good, Bad
> 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> v: height 768 start 771 end 777 total 806 clock 50.00Hz
> 1024x768 (0x45) 65.000MHz -HSync -VSync
> h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> v: height 768 start 771 end 777 total 806 clock 60.00Hz
> 1024x768 (0x46) 43.330MHz -HSync -VSync
> h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> v: height 768 start 771 end 777 total 806 clock 40.00Hz
> 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> v: height 720 start 720 end 722 total 750 clock 60.00Hz
> 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> v: height 696 start 696 end 698 total 719 clock 60.05Hz

Where are all these dblscan modes coming from?

Did you add them manually or are they being automatically
generated by something?

--
Ville Syrj?l?
Intel

2018-05-23 18:39:26

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > Hello all,
> > > > > >
> > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > without -window. I will try find time to build the latest rc this
> > > > > > evening.
> > > > > >
> > > > > > > ~$ xgalaga
> > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > Value in failed request: 0x120004e
> > > > > > > Serial number of failed request: 199
> > > > > > > Current serial number in output stream: 203
> > > > > >
> > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > It appears to be a 4.17-specific regression right now.
> > > > > >
> > > > > > Also observed, though this is surely a different regression, the game
> > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > >
> > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > >
> > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > >
> > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > playable on this machine in windowed mode when I last did.
> > > > > >
> > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > >
> > > > >
> > > > > Just built and booted v4.17-rc6, still broken.
> > > >
> > > > Bisected to:
> > > >
> > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > Author: Ville Syrj?l? <[email protected]>
> > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > >
> > > > drm/i915: Provide a device level .mode_valid() hook
> > > >
> > > > We never support certain mode flags etc. Reject those early on in the
> > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > we never see those flags even from user mode as the
> > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > >
> > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > Reviewed-by: Daniel Vetter <[email protected]>
> > >
> > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > the ddx doesn't validate before passing it on to the kernel. So far
> > > I can't reproduce the problem here unfortnately.
> > >
> > > Can you try the following patch and reproduce the problem with
> > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > modeline looks like?
> > >
> >
> > dmesg after xgalaga fails:
> >
> > ```
> > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
>
> 0x20 == dblscan
>
> > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > ```
> >
> > xrandr --verbose:
> >
> > ```
> > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > Identifier: 0x41
> > Timestamp: 23375
> > Subpixel: horizontal rgb
> > Gamma: 1.0:1.0:1.0
> > Brightness: 1.0
> > Clones:
> > CRTC: 0
> > CRTCs: 0 1
> > Transform: 1.000000 0.000000 0.000000
> > 0.000000 1.000000 0.000000
> > 0.000000 0.000000 1.000000
> > filter:
> > EDID:
> > 00ffffffffffff0030ae004000000000
> > 3010010380191278eafe609555518726
> > 22505421080001010101010101010101
> > 01010101010128150040410026301888
> > 3600f6b800000018ed10004041002630
> > 18883600f6b9000000180000000f0061
> > 43326143280f01000daf0714000000fe
> > 004e31323158352d4c303620202000ed
> > scaling mode: Full aspect
> > supported: Full, Center, Full aspect
> > non-desktop: 0
> > range: (0, 1)
> > link-status: Good
> > supported: Good, Bad
> > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > v: height 696 start 696 end 698 total 719 clock 60.05Hz
>
> Where are all these dblscan modes coming from?
>
> Did you add them manually or are they being automatically
> generated by something?
>

This is pure automagic xserver-xorg-video-intel on i915 drm/kms.

After booting back into a working 4.16 kernel I see the same xrandr --verbose
list with all the DoubleScan modes, with which xgalaga is functional.

There's this in the Xorg.log:

```
[ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
[ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
[ 12.882] (II) intel(0): Output VGA1 has no monitor section
[ 12.883] (II) intel(0): EDID for output LVDS1
[ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
[ 12.883] (II) intel(0): Year: 2006 Week: 48
[ 12.883] (II) intel(0): EDID Version: 1.3
[ 12.883] (II) intel(0): Digital Display Input
[ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
[ 12.883] (II) intel(0): Gamma: 2.20
[ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
[ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[ 12.883] (II) intel(0): First detailed timing is preferred mode
[ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
[ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
[ 12.883] (II) intel(0): Supported established timings:
[ 12.883] (II) intel(0): 640x480@60Hz
[ 12.883] (II) intel(0): 800x600@60Hz
[ 12.883] (II) intel(0): 1024x768@60Hz
[ 12.883] (II) intel(0): Manufacturer's mask: 0
[ 12.883] (II) intel(0): Supported detailed timing:
[ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
[ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
[ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
[ 12.883] (II) intel(0): Supported detailed timing:
[ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
[ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
[ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
[ 12.883] (II) intel(0): Unknown vendor-specific block f
[ 12.883] (II) intel(0): N121X5-L06
[ 12.883] (II) intel(0): EDID (in hex):
[ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
[ 12.883] (II) intel(0): 3010010380191278eafe609555518726
[ 12.883] (II) intel(0): 22505421080001010101010101010101
[ 12.883] (II) intel(0): 01010101010128150040410026301888
[ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
[ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
[ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
[ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
[ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
[ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
[ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
[ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
[ 12.884] (II) intel(0): Printing probed modes for output LVDS1
[ 12.884] (II) intel(0): Modeline "1024x768"x50.0 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (40.3 kHz eP)
[ 12.884] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 12.884] (II) intel(0): Modeline "1024x768"x40.0 43.33 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (32.2 kHz e)
[ 12.884] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 12.884] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d)
[ 12.884] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 12.906] (II) intel(0): EDID for output VGA1
[ 12.906] (II) intel(0): Output LVDS1 connected
[ 12.906] (II) intel(0): Output VGA1 disconnected
[ 12.906] (II) intel(0): Using exact sizes for initial modes
```

Thanks,
Vito Caputo

2018-05-23 19:12:53

by Ville Syrjälä

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > Hello all,
> > > > > > >
> > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > evening.
> > > > > > >
> > > > > > > > ~$ xgalaga
> > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > Value in failed request: 0x120004e
> > > > > > > > Serial number of failed request: 199
> > > > > > > > Current serial number in output stream: 203
> > > > > > >
> > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > >
> > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > >
> > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > >
> > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > >
> > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > >
> > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > >
> > > > > >
> > > > > > Just built and booted v4.17-rc6, still broken.
> > > > >
> > > > > Bisected to:
> > > > >
> > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > >
> > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > >
> > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > we never see those flags even from user mode as the
> > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > >
> > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > >
> > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > I can't reproduce the problem here unfortnately.
> > > >
> > > > Can you try the following patch and reproduce the problem with
> > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > modeline looks like?
> > > >
> > >
> > > dmesg after xgalaga fails:
> > >
> > > ```
> > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> >
> > 0x20 == dblscan
> >
> > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > ```
> > >
> > > xrandr --verbose:
> > >
> > > ```
> > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > Identifier: 0x41
> > > Timestamp: 23375
> > > Subpixel: horizontal rgb
> > > Gamma: 1.0:1.0:1.0
> > > Brightness: 1.0
> > > Clones:
> > > CRTC: 0
> > > CRTCs: 0 1
> > > Transform: 1.000000 0.000000 0.000000
> > > 0.000000 1.000000 0.000000
> > > 0.000000 0.000000 1.000000
> > > filter:
> > > EDID:
> > > 00ffffffffffff0030ae004000000000
> > > 3010010380191278eafe609555518726
> > > 22505421080001010101010101010101
> > > 01010101010128150040410026301888
> > > 3600f6b800000018ed10004041002630
> > > 18883600f6b9000000180000000f0061
> > > 43326143280f01000daf0714000000fe
> > > 004e31323158352d4c303620202000ed
> > > scaling mode: Full aspect
> > > supported: Full, Center, Full aspect
> > > non-desktop: 0
> > > range: (0, 1)
> > > link-status: Good
> > > supported: Good, Bad
> > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> >
> > Where are all these dblscan modes coming from?
> >
> > Did you add them manually or are they being automatically
> > generated by something?
> >
>
> This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
>
> After booting back into a working 4.16 kernel I see the same xrandr --verbose
> list with all the DoubleScan modes, with which xgalaga is functional.
>
> There's this in the Xorg.log:
>
> ```
> [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> [ 12.883] (II) intel(0): EDID for output LVDS1
> [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> [ 12.883] (II) intel(0): Year: 2006 Week: 48
> [ 12.883] (II) intel(0): EDID Version: 1.3
> [ 12.883] (II) intel(0): Digital Display Input
> [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> [ 12.883] (II) intel(0): Gamma: 2.20
> [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> [ 12.883] (II) intel(0): First detailed timing is preferred mode
> [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> [ 12.883] (II) intel(0): Supported established timings:
> [ 12.883] (II) intel(0): 640x480@60Hz
> [ 12.883] (II) intel(0): 800x600@60Hz
> [ 12.883] (II) intel(0): 1024x768@60Hz
> [ 12.883] (II) intel(0): Manufacturer's mask: 0
> [ 12.883] (II) intel(0): Supported detailed timing:
> [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> [ 12.883] (II) intel(0): Supported detailed timing:
> [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> [ 12.883] (II) intel(0): Unknown vendor-specific block f
> [ 12.883] (II) intel(0): N121X5-L06
> [ 12.883] (II) intel(0): EDID (in hex):
> [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> [ 12.883] (II) intel(0): 22505421080001010101010101010101
> [ 12.883] (II) intel(0): 01010101010128150040410026301888
> [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)

So first it rejected them all, but somehow later they get added back?
Very odd.

Hmm. Must be coming from that default modes thing...

Looks pretty much like ddx bug to me. Does the following ddx patch get
rid of the bogus dblscan modes?

From 40672b8527313d8bc01aa5cdcda8602687ec0f23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <[email protected]>
Date: Wed, 23 May 2018 22:10:07 +0300
Subject: [PATCH xf86-video-intel] Don't accept dblscan from xf86DefaultModes[]

---
src/sna/sna_display.c | 3 +++
src/uxa/intel_display.c | 3 +++
2 files changed, 6 insertions(+)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 6f6bea2e9cad..b38a915ca4ec 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -4204,6 +4204,8 @@ sna_output_add_default_modes(xf86OutputPtr output, DisplayModePtr modes)
DisplayModePtr i, m, preferred = NULL;
int max_x = 0, max_y = 0, max_clock = 0;
float max_vrefresh = 0.0;
+ int flags = (output->interlaceAllowed ? V_INTERLACE : 0) |
+ (output->doubleScanAllowed ? V_DBLSCAN : 0);

if (mon && GTF_SUPPORTED(mon->features.msc))
return modes;
@@ -4220,6 +4222,7 @@ sna_output_add_default_modes(xf86OutputPtr output, DisplayModePtr modes)

m = default_modes(preferred);
xf86ValidateModesSize(output->scrn, m, max_x, max_y, 0);
+ xf86ValidateModesFlags(output->scrn, m, flags);

for (i = m; i; i = i->next) {
if (i->Clock > max_clock)
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 809cda1dd56b..431727fc4ac2 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -919,6 +919,8 @@ intel_output_panel_edid(xf86OutputPtr output, DisplayModePtr modes)
DisplayModePtr i, m, p = NULL;
int max_x = 0, max_y = 0;
float max_vrefresh = 0.0;
+ int flags = (output->interlaceAllowed ? V_INTERLACE : 0) |
+ (output->doubleScanAllowed ? V_DBLSCAN : 0);

for (m = modes; m; m = m->next) {
if (m->type & M_T_PREFERRED)
@@ -938,6 +940,7 @@ intel_output_panel_edid(xf86OutputPtr output, DisplayModePtr modes)
#endif

xf86ValidateModesSize(output->scrn, m, max_x, max_y, 0);
+ xf86ValidateModesFlags(output->scrn, m, flags);

for (i = m; i; i = i->next) {
if (xf86ModeVRefresh(i) > max_vrefresh)
--
2.16.1

--
Ville Syrj?l?
Intel

2018-05-23 20:17:27

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrj?l? wrote:
> On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > > evening.
> > > > > > > >
> > > > > > > > > ~$ xgalaga
> > > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > > Value in failed request: 0x120004e
> > > > > > > > > Serial number of failed request: 199
> > > > > > > > > Current serial number in output stream: 203
> > > > > > > >
> > > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > >
> > > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > >
> > > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > > >
> > > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > >
> > > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > >
> > > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > >
> > > > > > >
> > > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > >
> > > > > > Bisected to:
> > > > > >
> > > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > > >
> > > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > > >
> > > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > > we never see those flags even from user mode as the
> > > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > > >
> > > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > > >
> > > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > > I can't reproduce the problem here unfortnately.
> > > > >
> > > > > Can you try the following patch and reproduce the problem with
> > > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > > modeline looks like?
> > > > >
> > > >
> > > > dmesg after xgalaga fails:
> > > >
> > > > ```
> > > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > >
> > > 0x20 == dblscan
> > >
> > > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > > ```
> > > >
> > > > xrandr --verbose:
> > > >
> > > > ```
> > > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > > Identifier: 0x41
> > > > Timestamp: 23375
> > > > Subpixel: horizontal rgb
> > > > Gamma: 1.0:1.0:1.0
> > > > Brightness: 1.0
> > > > Clones:
> > > > CRTC: 0
> > > > CRTCs: 0 1
> > > > Transform: 1.000000 0.000000 0.000000
> > > > 0.000000 1.000000 0.000000
> > > > 0.000000 0.000000 1.000000
> > > > filter:
> > > > EDID:
> > > > 00ffffffffffff0030ae004000000000
> > > > 3010010380191278eafe609555518726
> > > > 22505421080001010101010101010101
> > > > 01010101010128150040410026301888
> > > > 3600f6b800000018ed10004041002630
> > > > 18883600f6b9000000180000000f0061
> > > > 43326143280f01000daf0714000000fe
> > > > 004e31323158352d4c303620202000ed
> > > > scaling mode: Full aspect
> > > > supported: Full, Center, Full aspect
> > > > non-desktop: 0
> > > > range: (0, 1)
> > > > link-status: Good
> > > > supported: Good, Bad
> > > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> > >
> > > Where are all these dblscan modes coming from?
> > >
> > > Did you add them manually or are they being automatically
> > > generated by something?
> > >
> >
> > This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> >
> > After booting back into a working 4.16 kernel I see the same xrandr --verbose
> > list with all the DoubleScan modes, with which xgalaga is functional.
> >
> > There's this in the Xorg.log:
> >
> > ```
> > [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> > [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> > [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> > [ 12.883] (II) intel(0): EDID for output LVDS1
> > [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> > [ 12.883] (II) intel(0): Year: 2006 Week: 48
> > [ 12.883] (II) intel(0): EDID Version: 1.3
> > [ 12.883] (II) intel(0): Digital Display Input
> > [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> > [ 12.883] (II) intel(0): Gamma: 2.20
> > [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> > [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> > [ 12.883] (II) intel(0): First detailed timing is preferred mode
> > [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> > [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> > [ 12.883] (II) intel(0): Supported established timings:
> > [ 12.883] (II) intel(0): 640x480@60Hz
> > [ 12.883] (II) intel(0): 800x600@60Hz
> > [ 12.883] (II) intel(0): 1024x768@60Hz
> > [ 12.883] (II) intel(0): Manufacturer's mask: 0
> > [ 12.883] (II) intel(0): Supported detailed timing:
> > [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > [ 12.883] (II) intel(0): Supported detailed timing:
> > [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > [ 12.883] (II) intel(0): Unknown vendor-specific block f
> > [ 12.883] (II) intel(0): N121X5-L06
> > [ 12.883] (II) intel(0): EDID (in hex):
> > [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> > [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> > [ 12.883] (II) intel(0): 22505421080001010101010101010101
> > [ 12.883] (II) intel(0): 01010101010128150040410026301888
> > [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> > [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> > [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> > [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> > [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> > [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
>
> So first it rejected them all, but somehow later they get added back?
> Very odd.
>
> Hmm. Must be coming from that default modes thing...
>
> Looks pretty much like ddx bug to me. Does the following ddx patch get
> rid of the bogus dblscan modes?
>

<snip>

No, that didn't seem to change anything. After some digging, I found:

xorg-server-1.19.2/hw/xfree86/drivers/modesetting/drmmode_display.c::drmmode_output_init():

```
1796 drmmode_output->output_id = mode_res->connectors[num];
1797 drmmode_output->mode_output = koutput;
1798 drmmode_output->mode_encoders = kencoders;
1799 drmmode_output->drmmode = drmmode;
1800 output->mm_width = koutput->mmWidth;
1801 output->mm_height = koutput->mmHeight;
1802
1803 output->subpixel_order = subpixel_conv_table[koutput->subpixel];
1804 output->interlaceAllowed = TRUE;
1805 output->doubleScanAllowed = TRUE;
1806 output->driver_private = drmmode_output;
```

I don't see anywhere that sets interlaceAllowed or doubleScanAllowed to FALSE,
except xserver-xorg-video-intel/src/legacy/i810/i810_driver.c.

So your change never invalidates the doublescan modes, because they're allowed
for the output.

Assuming this can be corrected by disallowing these for the output
somewhere appropriate, isn't this still a userspace-breaking kernel
regression?

It seems to me like the kernel should just ignore the doublescan mode
flag and continue if a non-doublescan equivalent mode exists, given the
userspace situation this change uncovered.

Surely xgalaga isn't the only application using this API in such an
obvious fashion.

Thanks,
Vito Caputo

2018-05-23 20:42:12

by Ville Syrjälä

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > > > Hello all,
> > > > > > > > >
> > > > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > > > evening.
> > > > > > > > >
> > > > > > > > > > ~$ xgalaga
> > > > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > > > Value in failed request: 0x120004e
> > > > > > > > > > Serial number of failed request: 199
> > > > > > > > > > Current serial number in output stream: 203
> > > > > > > > >
> > > > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > > >
> > > > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > > >
> > > > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > > > >
> > > > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > > >
> > > > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > > >
> > > > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > > >
> > > > > > > Bisected to:
> > > > > > >
> > > > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > > > >
> > > > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > > > >
> > > > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > > > we never see those flags even from user mode as the
> > > > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > > > >
> > > > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > > > >
> > > > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > > > I can't reproduce the problem here unfortnately.
> > > > > >
> > > > > > Can you try the following patch and reproduce the problem with
> > > > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > > > modeline looks like?
> > > > > >
> > > > >
> > > > > dmesg after xgalaga fails:
> > > > >
> > > > > ```
> > > > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > > >
> > > > 0x20 == dblscan
> > > >
> > > > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > > > ```
> > > > >
> > > > > xrandr --verbose:
> > > > >
> > > > > ```
> > > > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > > > Identifier: 0x41
> > > > > Timestamp: 23375
> > > > > Subpixel: horizontal rgb
> > > > > Gamma: 1.0:1.0:1.0
> > > > > Brightness: 1.0
> > > > > Clones:
> > > > > CRTC: 0
> > > > > CRTCs: 0 1
> > > > > Transform: 1.000000 0.000000 0.000000
> > > > > 0.000000 1.000000 0.000000
> > > > > 0.000000 0.000000 1.000000
> > > > > filter:
> > > > > EDID:
> > > > > 00ffffffffffff0030ae004000000000
> > > > > 3010010380191278eafe609555518726
> > > > > 22505421080001010101010101010101
> > > > > 01010101010128150040410026301888
> > > > > 3600f6b800000018ed10004041002630
> > > > > 18883600f6b9000000180000000f0061
> > > > > 43326143280f01000daf0714000000fe
> > > > > 004e31323158352d4c303620202000ed
> > > > > scaling mode: Full aspect
> > > > > supported: Full, Center, Full aspect
> > > > > non-desktop: 0
> > > > > range: (0, 1)
> > > > > link-status: Good
> > > > > supported: Good, Bad
> > > > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> > > >
> > > > Where are all these dblscan modes coming from?
> > > >
> > > > Did you add them manually or are they being automatically
> > > > generated by something?
> > > >
> > >
> > > This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> > >
> > > After booting back into a working 4.16 kernel I see the same xrandr --verbose
> > > list with all the DoubleScan modes, with which xgalaga is functional.
> > >
> > > There's this in the Xorg.log:
> > >
> > > ```
> > > [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> > > [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> > > [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> > > [ 12.883] (II) intel(0): EDID for output LVDS1
> > > [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> > > [ 12.883] (II) intel(0): Year: 2006 Week: 48
> > > [ 12.883] (II) intel(0): EDID Version: 1.3
> > > [ 12.883] (II) intel(0): Digital Display Input
> > > [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> > > [ 12.883] (II) intel(0): Gamma: 2.20
> > > [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> > > [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> > > [ 12.883] (II) intel(0): First detailed timing is preferred mode
> > > [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> > > [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> > > [ 12.883] (II) intel(0): Supported established timings:
> > > [ 12.883] (II) intel(0): 640x480@60Hz
> > > [ 12.883] (II) intel(0): 800x600@60Hz
> > > [ 12.883] (II) intel(0): 1024x768@60Hz
> > > [ 12.883] (II) intel(0): Manufacturer's mask: 0
> > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > [ 12.883] (II) intel(0): Unknown vendor-specific block f
> > > [ 12.883] (II) intel(0): N121X5-L06
> > > [ 12.883] (II) intel(0): EDID (in hex):
> > > [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> > > [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> > > [ 12.883] (II) intel(0): 22505421080001010101010101010101
> > > [ 12.883] (II) intel(0): 01010101010128150040410026301888
> > > [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> > > [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> > > [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> > > [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> > > [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> > > [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
> >
> > So first it rejected them all, but somehow later they get added back?
> > Very odd.
> >
> > Hmm. Must be coming from that default modes thing...
> >
> > Looks pretty much like ddx bug to me. Does the following ddx patch get
> > rid of the bogus dblscan modes?
> >
>
> <snip>
>
> No, that didn't seem to change anything. After some digging, I found:
>
> xorg-server-1.19.2/hw/xfree86/drivers/modesetting/drmmode_display.c::drmmode_output_init():
>
> ```
> 1796 drmmode_output->output_id = mode_res->connectors[num];
> 1797 drmmode_output->mode_output = koutput;
> 1798 drmmode_output->mode_encoders = kencoders;
> 1799 drmmode_output->drmmode = drmmode;
> 1800 output->mm_width = koutput->mmWidth;
> 1801 output->mm_height = koutput->mmHeight;
> 1802
> 1803 output->subpixel_order = subpixel_conv_table[koutput->subpixel];
> 1804 output->interlaceAllowed = TRUE;
> 1805 output->doubleScanAllowed = TRUE;
> 1806 output->driver_private = drmmode_output;
> ```

That's the modesetting ddx. Irrelevant as long as you're using the intel
ddx.

>
> I don't see anywhere that sets interlaceAllowed or doubleScanAllowed to FALSE,
> except xserver-xorg-video-intel/src/legacy/i810/i810_driver.c.
>
> So your change never invalidates the doublescan modes, because they're allowed
> for the output.
>
> Assuming this can be corrected by disallowing these for the output
> somewhere appropriate, isn't this still a userspace-breaking kernel
> regression?

I suppose.

>
> It seems to me like the kernel should just ignore the doublescan mode
> flag and continue if a non-doublescan equivalent mode exists, given the
> userspace situation this change uncovered.

The only reason why ignoring it has worked is due to the panel fitter
being used on LVDS outputs. For other output types anyone trying to
use doublescan would probabably have gotten a fail or black/bogus
output.

This is the annoying part. I guess we want to ignore it for LVDS & co.
but reject it for everything else. Which means we have to allow it
into the kernel and reject it later. I guess for now we'll want to
move the check back into the connector .mode_valid() hooks and later
on we have to figure out how we can actually use those hooks to also
validate the user mode (which has been on the TODO list for
several years).

>
> Surely xgalaga isn't the only application using this API in such an
> obvious fashion.

Apart from xvidtune (which I don't think anyone uses anymore)
some games still use it in some fashion. Which is actually a
real pain because vidmode doesn't handle screen rotation at all.
I kinda wish it would disappear so at least games couldn't mess
up rotated display setups so easily.

--
Ville Syrj?l?
Intel

2018-05-23 21:28:50

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrj?l? wrote:
> On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > > > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > > > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > > > > Hello all,
> > > > > > > > > >
> > > > > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > > > > evening.
> > > > > > > > > >
> > > > > > > > > > > ~$ xgalaga
> > > > > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > > > > Value in failed request: 0x120004e
> > > > > > > > > > > Serial number of failed request: 199
> > > > > > > > > > > Current serial number in output stream: 203
> > > > > > > > > >
> > > > > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > > > >
> > > > > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > > > >
> > > > > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > > > > >
> > > > > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > > > >
> > > > > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > > > >
> > > > > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > > > >
> > > > > > > > Bisected to:
> > > > > > > >
> > > > > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > > > > >
> > > > > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > > > > >
> > > > > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > > > > we never see those flags even from user mode as the
> > > > > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > > > > >
> > > > > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > > > > >
> > > > > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > > > > I can't reproduce the problem here unfortnately.
> > > > > > >
> > > > > > > Can you try the following patch and reproduce the problem with
> > > > > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > > > > modeline looks like?
> > > > > > >
> > > > > >
> > > > > > dmesg after xgalaga fails:
> > > > > >
> > > > > > ```
> > > > > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > > > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > > > >
> > > > > 0x20 == dblscan
> > > > >
> > > > > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > > > > ```
> > > > > >
> > > > > > xrandr --verbose:
> > > > > >
> > > > > > ```
> > > > > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > > > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > > > > Identifier: 0x41
> > > > > > Timestamp: 23375
> > > > > > Subpixel: horizontal rgb
> > > > > > Gamma: 1.0:1.0:1.0
> > > > > > Brightness: 1.0
> > > > > > Clones:
> > > > > > CRTC: 0
> > > > > > CRTCs: 0 1
> > > > > > Transform: 1.000000 0.000000 0.000000
> > > > > > 0.000000 1.000000 0.000000
> > > > > > 0.000000 0.000000 1.000000
> > > > > > filter:
> > > > > > EDID:
> > > > > > 00ffffffffffff0030ae004000000000
> > > > > > 3010010380191278eafe609555518726
> > > > > > 22505421080001010101010101010101
> > > > > > 01010101010128150040410026301888
> > > > > > 3600f6b800000018ed10004041002630
> > > > > > 18883600f6b9000000180000000f0061
> > > > > > 43326143280f01000daf0714000000fe
> > > > > > 004e31323158352d4c303620202000ed
> > > > > > scaling mode: Full aspect
> > > > > > supported: Full, Center, Full aspect
> > > > > > non-desktop: 0
> > > > > > range: (0, 1)
> > > > > > link-status: Good
> > > > > > supported: Good, Bad
> > > > > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > > > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > > > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > > > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > > > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > > > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > > > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > > > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > > > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > > > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > > > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > > > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> > > > >
> > > > > Where are all these dblscan modes coming from?
> > > > >
> > > > > Did you add them manually or are they being automatically
> > > > > generated by something?
> > > > >
> > > >
> > > > This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> > > >
> > > > After booting back into a working 4.16 kernel I see the same xrandr --verbose
> > > > list with all the DoubleScan modes, with which xgalaga is functional.
> > > >
> > > > There's this in the Xorg.log:
> > > >
> > > > ```
> > > > [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> > > > [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> > > > [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> > > > [ 12.883] (II) intel(0): EDID for output LVDS1
> > > > [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> > > > [ 12.883] (II) intel(0): Year: 2006 Week: 48
> > > > [ 12.883] (II) intel(0): EDID Version: 1.3
> > > > [ 12.883] (II) intel(0): Digital Display Input
> > > > [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> > > > [ 12.883] (II) intel(0): Gamma: 2.20
> > > > [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> > > > [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> > > > [ 12.883] (II) intel(0): First detailed timing is preferred mode
> > > > [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> > > > [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> > > > [ 12.883] (II) intel(0): Supported established timings:
> > > > [ 12.883] (II) intel(0): 640x480@60Hz
> > > > [ 12.883] (II) intel(0): 800x600@60Hz
> > > > [ 12.883] (II) intel(0): 1024x768@60Hz
> > > > [ 12.883] (II) intel(0): Manufacturer's mask: 0
> > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > [ 12.883] (II) intel(0): Unknown vendor-specific block f
> > > > [ 12.883] (II) intel(0): N121X5-L06
> > > > [ 12.883] (II) intel(0): EDID (in hex):
> > > > [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> > > > [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> > > > [ 12.883] (II) intel(0): 22505421080001010101010101010101
> > > > [ 12.883] (II) intel(0): 01010101010128150040410026301888
> > > > [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> > > > [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> > > > [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> > > > [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> > > > [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> > > > [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
> > >
> > > So first it rejected them all, but somehow later they get added back?
> > > Very odd.
> > >
> > > Hmm. Must be coming from that default modes thing...
> > >
> > > Looks pretty much like ddx bug to me. Does the following ddx patch get
> > > rid of the bogus dblscan modes?
> > >
> >
> > <snip>
> >
> > No, that didn't seem to change anything. After some digging, I found:
> >
> > xorg-server-1.19.2/hw/xfree86/drivers/modesetting/drmmode_display.c::drmmode_output_init():
> >
> > ```
> > 1796 drmmode_output->output_id = mode_res->connectors[num];
> > 1797 drmmode_output->mode_output = koutput;
> > 1798 drmmode_output->mode_encoders = kencoders;
> > 1799 drmmode_output->drmmode = drmmode;
> > 1800 output->mm_width = koutput->mmWidth;
> > 1801 output->mm_height = koutput->mmHeight;
> > 1802
> > 1803 output->subpixel_order = subpixel_conv_table[koutput->subpixel];
> > 1804 output->interlaceAllowed = TRUE;
> > 1805 output->doubleScanAllowed = TRUE;
> > 1806 output->driver_private = drmmode_output;
> > ```
>
> That's the modesetting ddx. Irrelevant as long as you're using the intel
> ddx.
>

Hmm, that should have been obvious given the path, clearly I'm not
familiar with how this is structured. Xorg cannot start without
modesetting_drv.so, even when using intel_drv.so, so I thought they were
more intimately sharing functionality.

I wonder why the change didn't work then; intel_output_init() doesn't
set doubleScanAllowed=TRUE and xf86OutputCreate() uses calloc() so...

If you want me to test another patch I'm happy to. Even if the kernel
stays compatible with the bug, it still makes sense to fix userspace.

> >
> > I don't see anywhere that sets interlaceAllowed or doubleScanAllowed to FALSE,
> > except xserver-xorg-video-intel/src/legacy/i810/i810_driver.c.
> >
> > So your change never invalidates the doublescan modes, because they're allowed
> > for the output.
> >
> > Assuming this can be corrected by disallowing these for the output
> > somewhere appropriate, isn't this still a userspace-breaking kernel
> > regression?
>
> I suppose.
>
> >
> > It seems to me like the kernel should just ignore the doublescan mode
> > flag and continue if a non-doublescan equivalent mode exists, given the
> > userspace situation this change uncovered.
>
> The only reason why ignoring it has worked is due to the panel fitter
> being used on LVDS outputs. For other output types anyone trying to
> use doublescan would probabably have gotten a fail or black/bogus
> output.
>
> This is the annoying part. I guess we want to ignore it for LVDS & co.
> but reject it for everything else. Which means we have to allow it
> into the kernel and reject it later. I guess for now we'll want to
> move the check back into the connector .mode_valid() hooks and later
> on we have to figure out how we can actually use those hooks to also
> validate the user mode (which has been on the TODO list for
> several years).
>

This sounds like a reasonable interim solution.

Thanks,
Vito Caputo

2018-05-23 22:28:03

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrj?l? wrote:
> > > > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > > > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > > > > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > > > > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > > > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > > > > > Hello all,
> > > > > > > > > > >
> > > > > > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > > > > > evening.
> > > > > > > > > > >
> > > > > > > > > > > > ~$ xgalaga
> > > > > > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > > > > > Value in failed request: 0x120004e
> > > > > > > > > > > > Serial number of failed request: 199
> > > > > > > > > > > > Current serial number in output stream: 203
> > > > > > > > > > >
> > > > > > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > > > > >
> > > > > > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > > > > >
> > > > > > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > > > > > >
> > > > > > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > > > > >
> > > > > > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > > > > >
> > > > > > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > > > > >
> > > > > > > > > Bisected to:
> > > > > > > > >
> > > > > > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > > > > > >
> > > > > > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > > > > > >
> > > > > > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > > > > > we never see those flags even from user mode as the
> > > > > > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > > > > > >
> > > > > > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > > > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > > > > > I can't reproduce the problem here unfortnately.
> > > > > > > >
> > > > > > > > Can you try the following patch and reproduce the problem with
> > > > > > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > > > > > modeline looks like?
> > > > > > > >
> > > > > > >
> > > > > > > dmesg after xgalaga fails:
> > > > > > >
> > > > > > > ```
> > > > > > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > > > > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > > > > >
> > > > > > 0x20 == dblscan
> > > > > >
> > > > > > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > > > > > ```
> > > > > > >
> > > > > > > xrandr --verbose:
> > > > > > >
> > > > > > > ```
> > > > > > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > > > > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > > > > > Identifier: 0x41
> > > > > > > Timestamp: 23375
> > > > > > > Subpixel: horizontal rgb
> > > > > > > Gamma: 1.0:1.0:1.0
> > > > > > > Brightness: 1.0
> > > > > > > Clones:
> > > > > > > CRTC: 0
> > > > > > > CRTCs: 0 1
> > > > > > > Transform: 1.000000 0.000000 0.000000
> > > > > > > 0.000000 1.000000 0.000000
> > > > > > > 0.000000 0.000000 1.000000
> > > > > > > filter:
> > > > > > > EDID:
> > > > > > > 00ffffffffffff0030ae004000000000
> > > > > > > 3010010380191278eafe609555518726
> > > > > > > 22505421080001010101010101010101
> > > > > > > 01010101010128150040410026301888
> > > > > > > 3600f6b800000018ed10004041002630
> > > > > > > 18883600f6b9000000180000000f0061
> > > > > > > 43326143280f01000daf0714000000fe
> > > > > > > 004e31323158352d4c303620202000ed
> > > > > > > scaling mode: Full aspect
> > > > > > > supported: Full, Center, Full aspect
> > > > > > > non-desktop: 0
> > > > > > > range: (0, 1)
> > > > > > > link-status: Good
> > > > > > > supported: Good, Bad
> > > > > > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > > > > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > > > > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > > > > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > > > > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > > > > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > > > > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > > > > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > > > > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > > > > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > > > > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > > > > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> > > > > >
> > > > > > Where are all these dblscan modes coming from?
> > > > > >
> > > > > > Did you add them manually or are they being automatically
> > > > > > generated by something?
> > > > > >
> > > > >
> > > > > This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> > > > >
> > > > > After booting back into a working 4.16 kernel I see the same xrandr --verbose
> > > > > list with all the DoubleScan modes, with which xgalaga is functional.
> > > > >
> > > > > There's this in the Xorg.log:
> > > > >
> > > > > ```
> > > > > [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> > > > > [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> > > > > [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> > > > > [ 12.883] (II) intel(0): EDID for output LVDS1
> > > > > [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> > > > > [ 12.883] (II) intel(0): Year: 2006 Week: 48
> > > > > [ 12.883] (II) intel(0): EDID Version: 1.3
> > > > > [ 12.883] (II) intel(0): Digital Display Input
> > > > > [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> > > > > [ 12.883] (II) intel(0): Gamma: 2.20
> > > > > [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> > > > > [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> > > > > [ 12.883] (II) intel(0): First detailed timing is preferred mode
> > > > > [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> > > > > [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> > > > > [ 12.883] (II) intel(0): Supported established timings:
> > > > > [ 12.883] (II) intel(0): 640x480@60Hz
> > > > > [ 12.883] (II) intel(0): 800x600@60Hz
> > > > > [ 12.883] (II) intel(0): 1024x768@60Hz
> > > > > [ 12.883] (II) intel(0): Manufacturer's mask: 0
> > > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > > [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> > > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > > [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> > > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > > [ 12.883] (II) intel(0): Unknown vendor-specific block f
> > > > > [ 12.883] (II) intel(0): N121X5-L06
> > > > > [ 12.883] (II) intel(0): EDID (in hex):
> > > > > [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> > > > > [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> > > > > [ 12.883] (II) intel(0): 22505421080001010101010101010101
> > > > > [ 12.883] (II) intel(0): 01010101010128150040410026301888
> > > > > [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> > > > > [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> > > > > [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> > > > > [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> > > > > [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > > [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> > > > > [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
> > > >
> > > > So first it rejected them all, but somehow later they get added back?
> > > > Very odd.
> > > >
> > > > Hmm. Must be coming from that default modes thing...
> > > >
> > > > Looks pretty much like ddx bug to me. Does the following ddx patch get
> > > > rid of the bogus dblscan modes?
> > > >
> > >
> > > <snip>
> > >
> > > No, that didn't seem to change anything. After some digging, I found:
> > >
> > > xorg-server-1.19.2/hw/xfree86/drivers/modesetting/drmmode_display.c::drmmode_output_init():
> > >
> > > ```
> > > 1796 drmmode_output->output_id = mode_res->connectors[num];
> > > 1797 drmmode_output->mode_output = koutput;
> > > 1798 drmmode_output->mode_encoders = kencoders;
> > > 1799 drmmode_output->drmmode = drmmode;
> > > 1800 output->mm_width = koutput->mmWidth;
> > > 1801 output->mm_height = koutput->mmHeight;
> > > 1802
> > > 1803 output->subpixel_order = subpixel_conv_table[koutput->subpixel];
> > > 1804 output->interlaceAllowed = TRUE;
> > > 1805 output->doubleScanAllowed = TRUE;
> > > 1806 output->driver_private = drmmode_output;
> > > ```
> >
> > That's the modesetting ddx. Irrelevant as long as you're using the intel
> > ddx.
> >
>
> Hmm, that should have been obvious given the path, clearly I'm not
> familiar with how this is structured. Xorg cannot start without
> modesetting_drv.so, even when using intel_drv.so, so I thought they were
> more intimately sharing functionality.
>
> I wonder why the change didn't work then; intel_output_init() doesn't
> set doubleScanAllowed=TRUE and xf86OutputCreate() uses calloc() so...
>

I just noticed something important. I've been looking at old Xorg logs
in /var/log, it appears at some point these things moved into
~/.local/share/xorg/.

Look at the *current* logs, it looks like my xorg is using the modeset
driver. This explains why removing modeset_drv.so breaks things.

It also explains why your xorg-video-intel patch made no difference.

As the code excerpt above illustrates, the modeset driver is enabling
both interlaceAllowed and doubleScanAllowed, so we know where it's
getting those.

Apologies for any confusion, my /var/log/ is full of Xorg.%i.log files
but they're from 2017 *sigh*.

Regards,
Vito Caputo

2018-05-24 00:23:42

by Vito Caputo

[permalink] [raw]
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen (default) mode

On Wed, May 23, 2018 at 03:27:34PM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 02:27:48PM -0700, Vito Caputo wrote:
> > On Wed, May 23, 2018 at 11:41:25PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 23, 2018 at 01:15:05PM -0700, Vito Caputo wrote:
> > > > On Wed, May 23, 2018 at 10:12:22PM +0300, Ville Syrj?l? wrote:
> > > > > On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> > > > > > On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrj?l? wrote:
> > > > > > > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > > > > > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrj?l? wrote:
> > > > > > > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > > > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > > > > > > Hello all,
> > > > > > > > > > > >
> > > > > > > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > > > > > > without -window. I will try find time to build the latest rc this
> > > > > > > > > > > > evening.
> > > > > > > > > > > >
> > > > > > > > > > > > > ~$ xgalaga
> > > > > > > > > > > > > X Error of failed request: BadValue (integer parameter out of range for operation)
> > > > > > > > > > > > > Major opcode of failed request: 152 (XFree86-VidModeExtension)
> > > > > > > > > > > > > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
> > > > > > > > > > > > > Value in failed request: 0x120004e
> > > > > > > > > > > > > Serial number of failed request: 199
> > > > > > > > > > > > > Current serial number in output stream: 203
> > > > > > > > > > > >
> > > > > > > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > > > > > >
> > > > > > > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > > > > > >
> > > > > > > > > > > > 692 vc 20 0 312852 45884 20556 R 32.0 1.2 0:08.69 Xorg
> > > > > > > > > > > > 102 root 20 0 0 0 0 R 11.2 0.0 0:01.43 kworker/1:3
> > > > > > > > > > > > 94 root 20 0 0 0 0 I 8.9 0.0 0:00.83 kworker/0:2
> > > > > > > > > > > > 696 vc 20 0 39948 4124 2912 S 1.0 0.1 0:05.57 vwm
> > > > > > > > > > > > 902 vc 30 10 46372 4144 3500 S 0.7 0.1 0:00.08 xgalaga
> > > > > > > > > > > > 891 vc 30 10 44924 3868 3156 R 0.3 0.1 0:00.09 top
> > > > > > > > > > > > 903 vc 30 10 4180 1184 1100 S 0.3 0.0 0:00.01 xgal.sndsrv.oss
> > > > > > > > > > > >
> > > > > > > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > > > > > >
> > > > > > > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > > > > > >
> > > > > > > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > > > > > >
> > > > > > > > > > Bisected to:
> > > > > > > > > >
> > > > > > > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > > > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > > > > > > Author: Ville Syrj?l? <[email protected]>
> > > > > > > > > > Date: Tue Nov 14 20:32:58 2017 +0200
> > > > > > > > > >
> > > > > > > > > > drm/i915: Provide a device level .mode_valid() hook
> > > > > > > > > >
> > > > > > > > > > We never support certain mode flags etc. Reject those early on in the
> > > > > > > > > > mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > > > > > > > checks from the connector .mode_valid() hooks, and it guarantees that
> > > > > > > > > > we never see those flags even from user mode as the
> > > > > > > > > > mode_config.mode_valid() hooks gets executed for those as well.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Ville Syrj?l? <[email protected]>
> > > > > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
> > > > > > > > > > Reviewed-by: Daniel Vetter <[email protected]>
> > > > > > > > >
> > > > > > > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > > > > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > > > > > > I can't reproduce the problem here unfortnately.
> > > > > > > > >
> > > > > > > > > Can you try the following patch and reproduce the problem with
> > > > > > > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > > > > > > modeline looks like?
> > > > > > > > >
> > > > > > > >
> > > > > > > > dmesg after xgalaga fails:
> > > > > > > >
> > > > > > > > ```
> > > > > > > > [ 75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > > > > > > [ 75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > > > > > >
> > > > > > > 0x20 == dblscan
> > > > > > >
> > > > > > > > [ 75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > > > > > > ```
> > > > > > > >
> > > > > > > > xrandr --verbose:
> > > > > > > >
> > > > > > > > ```
> > > > > > > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > > > > > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > > > > > > Identifier: 0x41
> > > > > > > > Timestamp: 23375
> > > > > > > > Subpixel: horizontal rgb
> > > > > > > > Gamma: 1.0:1.0:1.0
> > > > > > > > Brightness: 1.0
> > > > > > > > Clones:
> > > > > > > > CRTC: 0
> > > > > > > > CRTCs: 0 1
> > > > > > > > Transform: 1.000000 0.000000 0.000000
> > > > > > > > 0.000000 1.000000 0.000000
> > > > > > > > 0.000000 0.000000 1.000000
> > > > > > > > filter:
> > > > > > > > EDID:
> > > > > > > > 00ffffffffffff0030ae004000000000
> > > > > > > > 3010010380191278eafe609555518726
> > > > > > > > 22505421080001010101010101010101
> > > > > > > > 01010101010128150040410026301888
> > > > > > > > 3600f6b800000018ed10004041002630
> > > > > > > > 18883600f6b9000000180000000f0061
> > > > > > > > 43326143280f01000daf0714000000fe
> > > > > > > > 004e31323158352d4c303620202000ed
> > > > > > > > scaling mode: Full aspect
> > > > > > > > supported: Full, Center, Full aspect
> > > > > > > > non-desktop: 0
> > > > > > > > range: (0, 1)
> > > > > > > > link-status: Good
> > > > > > > > supported: Good, Bad
> > > > > > > > 1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
> > > > > > > > v: height 768 start 771 end 777 total 806 clock 50.00Hz
> > > > > > > > 1024x768 (0x45) 65.000MHz -HSync -VSync
> > > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
> > > > > > > > v: height 768 start 771 end 777 total 806 clock 60.00Hz
> > > > > > > > 1024x768 (0x46) 43.330MHz -HSync -VSync
> > > > > > > > h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
> > > > > > > > v: height 768 start 771 end 777 total 806 clock 40.00Hz
> > > > > > > > 960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > > > > > > > h: width 960 start 1024 end 1128 total 1300 skew 0 clock 90.00KHz
> > > > > > > > v: height 720 start 720 end 722 total 750 clock 60.00Hz
> > > > > > > > 928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > > > > > > > h: width 928 start 976 end 1088 total 1264 skew 0 clock 86.35KHz
> > > > > > > > v: height 696 start 696 end 698 total 719 clock 60.05Hz
> > > > > > >
> > > > > > > Where are all these dblscan modes coming from?
> > > > > > >
> > > > > > > Did you add them manually or are they being automatically
> > > > > > > generated by something?
> > > > > > >
> > > > > >
> > > > > > This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> > > > > >
> > > > > > After booting back into a working 4.16 kernel I see the same xrandr --verbose
> > > > > > list with all the DoubleScan modes, with which xgalaga is functional.
> > > > > >
> > > > > > There's this in the Xorg.log:
> > > > > >
> > > > > > ```
> > > > > > [ 12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> > > > > > [ 12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> > > > > > [ 12.882] (II) intel(0): Output VGA1 has no monitor section
> > > > > > [ 12.883] (II) intel(0): EDID for output LVDS1
> > > > > > [ 12.883] (II) intel(0): Manufacturer: LEN Model: 4000 Serial#: 0
> > > > > > [ 12.883] (II) intel(0): Year: 2006 Week: 48
> > > > > > [ 12.883] (II) intel(0): EDID Version: 1.3
> > > > > > [ 12.883] (II) intel(0): Digital Display Input
> > > > > > [ 12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25 vert.: 18
> > > > > > [ 12.883] (II) intel(0): Gamma: 2.20
> > > > > > [ 12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> > > > > > [ 12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> > > > > > [ 12.883] (II) intel(0): First detailed timing is preferred mode
> > > > > > [ 12.883] (II) intel(0): redX: 0.585 redY: 0.335 greenX: 0.319 greenY: 0.529
> > > > > > [ 12.883] (II) intel(0): blueX: 0.149 blueY: 0.135 whiteX: 0.312 whiteY: 0.328
> > > > > > [ 12.883] (II) intel(0): Supported established timings:
> > > > > > [ 12.883] (II) intel(0): 640x480@60Hz
> > > > > > [ 12.883] (II) intel(0): 800x600@60Hz
> > > > > > [ 12.883] (II) intel(0): 1024x768@60Hz
> > > > > > [ 12.883] (II) intel(0): Manufacturer's mask: 0
> > > > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > > > [ 12.883] (II) intel(0): clock: 54.2 MHz Image Size: 246 x 184 mm
> > > > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > > > [ 12.883] (II) intel(0): Supported detailed timing:
> > > > > > [ 12.883] (II) intel(0): clock: 43.3 MHz Image Size: 246 x 185 mm
> > > > > > [ 12.883] (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
> > > > > > [ 12.883] (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
> > > > > > [ 12.883] (II) intel(0): Unknown vendor-specific block f
> > > > > > [ 12.883] (II) intel(0): N121X5-L06
> > > > > > [ 12.883] (II) intel(0): EDID (in hex):
> > > > > > [ 12.883] (II) intel(0): 00ffffffffffff0030ae004000000000
> > > > > > [ 12.883] (II) intel(0): 3010010380191278eafe609555518726
> > > > > > [ 12.883] (II) intel(0): 22505421080001010101010101010101
> > > > > > [ 12.883] (II) intel(0): 01010101010128150040410026301888
> > > > > > [ 12.883] (II) intel(0): 3600f6b800000018ed10004041002630
> > > > > > [ 12.883] (II) intel(0): 18883600f6b9000000180000000f0061
> > > > > > [ 12.883] (II) intel(0): 43326143280f01000daf0714000000fe
> > > > > > [ 12.883] (II) intel(0): 004e31323158352d4c303620202000ed
> > > > > > [ 12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > > > [ 12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> > > > > > [ 12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> > > > > > [ 12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)
> > > > >
> > > > > So first it rejected them all, but somehow later they get added back?
> > > > > Very odd.
> > > > >
> > > > > Hmm. Must be coming from that default modes thing...
> > > > >
> > > > > Looks pretty much like ddx bug to me. Does the following ddx patch get
> > > > > rid of the bogus dblscan modes?
> > > > >
> > > >
> > > > <snip>
> > > >
> > > > No, that didn't seem to change anything. After some digging, I found:
> > > >
> > > > xorg-server-1.19.2/hw/xfree86/drivers/modesetting/drmmode_display.c::drmmode_output_init():
> > > >
> > > > ```
> > > > 1796 drmmode_output->output_id = mode_res->connectors[num];
> > > > 1797 drmmode_output->mode_output = koutput;
> > > > 1798 drmmode_output->mode_encoders = kencoders;
> > > > 1799 drmmode_output->drmmode = drmmode;
> > > > 1800 output->mm_width = koutput->mmWidth;
> > > > 1801 output->mm_height = koutput->mmHeight;
> > > > 1802
> > > > 1803 output->subpixel_order = subpixel_conv_table[koutput->subpixel];
> > > > 1804 output->interlaceAllowed = TRUE;
> > > > 1805 output->doubleScanAllowed = TRUE;
> > > > 1806 output->driver_private = drmmode_output;
> > > > ```
> > >
> > > That's the modesetting ddx. Irrelevant as long as you're using the intel
> > > ddx.
> > >
> >
> > Hmm, that should have been obvious given the path, clearly I'm not
> > familiar with how this is structured. Xorg cannot start without
> > modesetting_drv.so, even when using intel_drv.so, so I thought they were
> > more intimately sharing functionality.
> >
> > I wonder why the change didn't work then; intel_output_init() doesn't
> > set doubleScanAllowed=TRUE and xf86OutputCreate() uses calloc() so...
> >
>
> I just noticed something important. I've been looking at old Xorg logs
> in /var/log, it appears at some point these things moved into
> ~/.local/share/xorg/.
>
> Look at the *current* logs, it looks like my xorg is using the modeset
> driver. This explains why removing modeset_drv.so breaks things.
>
> It also explains why your xorg-video-intel patch made no difference.
>
> As the code excerpt above illustrates, the modeset driver is enabling
> both interlaceAllowed and doubleScanAllowed, so we know where it's
> getting those.
>
> Apologies for any confusion, my /var/log/ is full of Xorg.%i.log files
> but they're from 2017 *sigh*.
>

I've just built and tested the modesetting driver with:
- output->doubleScanAllowed = TRUE;
+ output->doubleScanAllowed = FALSE;

and it fixes xgalaga on 4.17-rc6.

xrandr --verbose output is now:

```
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
Identifier: 0x41
Timestamp: 16465276
Subpixel: horizontal rgb
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 0
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff0030ae004000000000
3010010380191278eafe609555518726
22505421080001010101010101010101
01010101010128150040410026301888
3600f6b800000018ed10004041002630
18883600f6b9000000180000000f0061
43326143280f01000daf0714000000fe
004e31323158352d4c303620202000ed
scaling mode: Full aspect
supported: Full, Center, Full aspect
non-desktop: 0
range: (0, 1)
link-status: Good
supported: Good, Bad
1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.30KHz
v: height 768 start 771 end 777 total 806 clock 50.00Hz
1024x768 (0x45) 65.000MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
v: height 768 start 771 end 777 total 806 clock 60.00Hz
1024x768 (0x46) 43.330MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 32.24KHz
v: height 768 start 771 end 777 total 806 clock 40.00Hz
800x600 (0x47) 40.000MHz +HSync +VSync
h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz
v: height 600 start 601 end 605 total 628 clock 60.32Hz
800x600 (0x48) 36.000MHz +HSync +VSync
h: width 800 start 824 end 896 total 1024 skew 0 clock 35.16KHz
v: height 600 start 601 end 603 total 625 clock 56.25Hz
640x480 (0x49) 25.175MHz -HSync -VSync
h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz
v: height 480 start 490 end 492 total 525 clock 59.94Hz
VGA-1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp: 16465276
Subpixel: unknown
Clones:
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
non-desktop: 0
range: (0, 1)
link-status: Good
supported: Good, Bad
```

So if you're going to fix the xserver-xorg-video-intel driver, it looks like
the modesetting driver should also be corrected in the same way.

Now to figure out why Debian doesn't package modesetting_drv.so as
xserver-xorg-video-$variant, which results in requiring something like
xserver-xorg-video-intel even when modesetting is in use.

Regards,
Vito Caputo