Created attachment 140000 [details] xorg log xserver 1.20, kernel 4.17 and modesetting fails: [ 126.170] (EE) modeset(0): failed to set mode: Invalid argument while it works fine on 4.16 kernel. Bisected to commit below and indeed, reverting it on current kernel git makes the problem go away. commit e995ca0b8139c5f6807095464e969931b443f55a Author: Ville Syrjälä <ville.syrjala@linux.intel.com> 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-11-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From strace: 1880 ioctl(14, DRM_IOCTL_I915_GEM_MMAP <unfinished ...> 1895 <... read resumed> 0x2163e98, 7752) = -1 EAGAIN (Resource temporarily unavailable) 1880 <... ioctl resumed> , 0x7ffe47fdf6b0) = 0 1895 read(37, 0x2163e80, 7776) = -1 EAGAIN (Resource temporarily unavailable) 1895 read(37, 0x2163e68, 7800) = -1 EAGAIN (Resource temporarily unavailable) 1895 read(37, <unfinished ...> 1880 ioctl(16, DRM_IOCTL_MODE_LIST_LESSEES <unfinished ...> 1895 <... read resumed> 0x2163e50, 7824) = -1 EAGAIN (Resource temporarily unavailable) 1880 <... ioctl resumed> , 0x7ffe47fdf9a0) = 0 1880 ioctl(16, DRM_IOCTL_MODE_LIST_LESSEES, 0x7ffe47fdf9a0) = 0 1880 ioctl(14, DRM_IOCTL_MODE_DIRTYFB, 0x7ffe47fdf980) = -1 ENOENT (No such file or directory) 1880 ioctl(14, DRM_IOCTL_MODE_SETGAMMA <unfinished ...> 1895 write(22, "\0", 1) = 1 1895 epoll_wait(25, <unfinished ...> 1880 <... ioctl resumed> , 0x7ffe47fdf8e0) = 0 1880 ioctl(14, DRM_IOCTL_MODE_ADDFB2, 0x7ffe47fdf6e0) = 0 1880 ioctl(14, DRM_IOCTL_MODE_CREATEPROPBLOB, 0x7ffe47fdf740) = 0 1880 ioctl(14, DRM_IOCTL_MODE_ATOMIC, 0x7ffe47fdf7f0) = -1 EINVAL (Invalid argument) 1880 write(4, "[ 126.170] ", 13) = 13 1880 write(4, "(EE) modeset(0): failed to set mode: Invalid argument\n", 54) = 54 1880 epoll_wait(3, [{EPOLLIN, {u32=31794656, u64=31794656}}], 256, 599996) = 1
drm.debug=0x1f ?
Created attachment 140001 [details] dmesg with debug
That was done back then but with 0xe, is that enough?
0x1f gives slightly more useful information.
Created attachment 140003 [details] drm debug 0x1f
Do you happen to have the Xorg log from the same run? I want to see the timing of Xorg.0.log versus that dmesg, so I can see where it fails exactly on what call.
hm then again guessing it's the first atomic call that fails with -22, probably in drm_mode_convert_umode from drm_atomic_set_mode_prop_for_crtc. Probably intel_mode_valid that fails, could you dump mode->flags ?
Oh nm, the clue is in the Xorg log.. [ 123.751] (II) modeset(0): Printing probed modes for output eDP-1 [ 123.751] (II) modeset(0): Modeline "1920x1080"x120.0 356.38 1920 2080 2288 2656 1080 1081 1084 1118 doublescan -hsync +vsync (134.2 kHz UdP) [ 123.751] (II) modeset(0): Modeline "3200x1800"x60.0 373.25 3200 3248 3280 3360 1800 1803 1808 1852 -hsync -vsync (111.1 kHz eP) [ 123.751] (II) modeset(0): Modeline "3200x1800"x60.0 492.00 3200 3456 3800 4400 1800 1803 1808 1865 -hsync +vsync (111.8 kHz d) [ 123.751] (II) modeset(0): Modeline "3200x1800"x59.9 373.00 3200 3248 3280 3360 1800 1803 1808 1852 +hsync -vsync (111.0 kHz d) doublescan being set somehow..
Possibly fixed by: https://patchwork.freedesktop.org/patch/225189/ The bigger mystery is why modesetting would default to a dblscan mode. That makes no sense. Sadly our debugs for atomic are woefully inadequate so the logs don't contain the reason for the failure :(
That patch fixes it for me. No xorg.log from the same run but can make it if needed.
btw. this laptop has native 3200x1800 screen resolution but I'm using: Modes "1920x1080" in xorg.conf
Ah, that is the missing piece why it chooses that mode. X.org is borked and just sets doublescan/interlaced is always possible with modesetting: output->interlaceAllowed = TRUE; output->doubleScanAllowed = TRUE; And because it has the highest clock, you get your 1920 mode with doublescan..
(In reply to Maarten Lankhorst from comment #13) > Ah, that is the missing piece why it chooses that mode. > X.org is borked and just sets doublescan/interlaced is always possible with > modesetting: > output->interlaceAllowed = TRUE; > output->doubleScanAllowed = TRUE; > > And because it has the highest clock, you get your 1920 mode with > doublescan.. Also the mode flags aren't even checked by the xf86DefaulltModes stuff. So even if we set doubleScanAllowed=FALSE we'd still get doublescan modes in the list :(
commit e4dd27aadd205417a2e9ea9902b698a0252ec3a0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 24 15:54:03 2018 +0300 drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
Push it to -stable please.
(In reply to Arkadiusz Miskiewicz from comment #16) > Push it to -stable please. The patch has cc:stable, so it'll get there eventually.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.