Hello, xrandr crashes if a monitor is attached with a custom xrandr mode. Custom xrandr modes are useful when video card and monitor don't work together by default. So I have this script: $ cvt 1920 1080 65 # 1920x1080 64.93 Hz (CVT) hsync: 72.98 kHz; pclk: 188.00 MHz Modeline "1920x1080_65.00" 188.00 1920 2048 2248 2576 1080 1083 1088 1124 -hsync +vsync $ xrandr --newmode "1920x1080_65.00" 188.00 1920 2048 2248 2576 1080 1083 1088 1124 -hsync +vsync $ xrandr --addmode VGA1 1920x1080_65.00 $ xrandr --output VGA1 --mode 1920x1080_65.00 --below LVDS1 When trying to start xfsettings I see in console: (xfsettingsd:2795): Gdk-ERROR **: The program 'xfsettingsd' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 130 error_code 8 request_code 139 minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) This is too bad because a lot of my settings are not applied ever, like touchpad settings and others.
Hello, It would be great if you could provide additional information, at least the output of "XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon" when you reproduce the crash. It would be even better if you could provide a backtrace of the crash using gdb. Thanks in advance, Jérôme
Created attachment 4811 backtrace from the abrt tool Hello again, I'm attaching a backtrace generated by the abrt tool. Please let me know if you see anything inconsistent in this one so I can try generating one manually.
Created attachment 4812 new backtrace from the abrt tool Attaching a backtrace from freshly reproduced crash. Also You can see below the debug output, strange it doesn't look verbose to me. I think it would be simple to reproduce by yourself. The problem also seems to happen when an external monitor is attached but not configured in settings-manager. Not sure this easier reproducer is reliable though. $ XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon xfce4-settings(xsettings): _XSETTINGS_S0 registered on screen 0 xfce4-settings(xsettings): 4 settings changed (serial=0, len=164) xfce4-settings(xsettings): resource manager (xft) changed (len=98) (xfsettingsd:1537): xfsettingsd-WARNING **: Unknown mode '1920x1080 @ 64.9' for output VGA1. (xfsettingsd:1537): Gdk-ERROR **: The program 'xfsettingsd' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 134 error_code 8 request_code 139 minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap (core dumped)
Is it the correct stacktrace? > #10 0x08052229 in xfce_pointers_helper_init (helper=0x96d9160) at pointers.c:129 The crash seems to be unrelated to the randr mode, but rather to the XI or XI2 extension support.
Mmmh, you didn't pass '--sync' though, so this might be caused by the randr code... Can you try to get a new trace by following the instructions of the error message: > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.
hmm, running with --sync the process does not crash. Running without sync it always crashes but with --sync never... sounds like a Christmas present :) The "Unknown mode '1920x1080 @ 64.9' for output VGA1." message is still in the output. And monitor mode is not set as desired. But there is no crash. Could it be that the xrandr code guard against errors with the calls but being async a signal is sent that is uncaught? Excuse me, I'm just speculating because I've no idea about the code.
bump, not sure why needinfo flag is not removed by my last reply but I've no idea what information more I can provide.
I can repeat this problem. I have my laptop and I have two different monitors: 1) At Home, 1920x1200, from BrandA 2) At Work, 1920x1080, from BrandB When I shutdown at home & boot at work, xfsettingsd crashes, I can understand as my appearance customizations are not applied. I see the following message when I try to start it manually: (xfsettingsd:2439): xfsettingsd-WARNING **: Unknown mode '1920x1200 @ 60.0' for output VGA1. The program 'xfsettingsd' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 143 error_code 8 request_code 140 minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Why does xfsettingsd try to stick to a given resolution on external display? Can't it just try "auto" resolution just like xrandr does? the way I setup my screen with xrandr is as follows (as I can't do it with display applet in XFCE settings, it does not let me chose orientation of monitors neither "auto" for resolution: xrandr --output VGA1 --primary --auto --output LVDS1 --auto --below VGA1 Once you get xfsettingsd running after deleting displays.xml, changing resolution from displays applet, it starts to work, then you can re-trigger xrandr to adjust the desired screen resolution & layout.
Hello again, can somebody move this issue out of NEEDINFO state. I can put it only in RESOLVED state but it is not yet resolved. Somebody just reported the issue still happens with xfce4-settings-4.10 I'm not sure what the fix would be but it seems a good workaround is to start the daemon in sync mode. Can that be easily done?
Hello, I am having the same issue with dual screens but without the unknown mode error. So maybe this is not related to the mode. Here is what I have: $ XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon xfce4-settings(xsettings): _XSETTINGS_S0 registered on screen 0 xfce4-settings(xsettings): 26 settings changed (serial=0, len=1020) xfce4-settings(xsettings): resource manager (xft) changed (len=117) The program 'xfsettingsd' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 132 error_code 8 request_code 140 minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) With these xrandr settings: $ xrandr Screen 0: minimum 8 x 8, current 2960 x 1050, maximum 8192 x 8192 VGA-0 connected 1280x1024+1680+26 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 LVDS-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.0*+ 50.0 DVI-D-0 disconnected (normal left inverted right x axis y axis) Regards, Pierre
Hi, Some additionnal info on my side: $ pacman -Q xfce4-settings xfce4-settings 4.10.1-1 Also, the --sync is working for me too. Maybe a fallback system trying first async and then switching to sync would fix this issue? Regards, Pierre
Marking as ASSIGNED for Nick then.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/16. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev