[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: X unstable / integrated graphics chipset



On 2025-11-20 at 08:01, Seb wrote:

>> (A solution seems to have been found!)
> 
> It was too early to call it a day: once the central unit is connected
> to a larger screen (max resolution 2560x1440), xrandr offers no more
> than 1920x1280.

In some cases, xrandr may not detect/suggest/offer resolution modes
which might actually work just fine.

The case in which I've seen that is one in which the resolution I want
is *smaller* than the largest xrandr offers, so I don't know for sure
whether trying to go higher can work, but it might be worth a try.
Caveat emptor; attempt at your own risk.

What can be done in such cases is to generate an X modeline for the
desired resolution separately, then pass that modeline to xrandr in a
way that tells it to offer this.

The simplest way I know of to generate a valid modeline is by way of the
tool 'cvt'.

In my case, I wanted a resolution of 2560x1600 (on a monitor capable of
3840x2160, which at this physical monitor size produces text etc. too
small for my eyes), so I ran:
  cvt 2560 1600
and then plugged the output into a hand-written ~/.xinitrc file. It
would probably be more ideal to run that command in the script itself,
but at the time I didn't want to do the gymnastics to extract just the
parts of the cvt output that I needed to pass to xrandr, and since then
it's been Just Work'ing well enough that I haven't felt the need to
revisit the matter.

Once I had the modeline, I needed to first tell xrandr about that mode via
  xrandr --newmode
, then tell xrandr to link that mode with a particular "X output", i.e.
monitor (which happens to be the only one I keep connected), via
  xrandr --addmode
, then finally tell xrandr to switch that output to the mode just added,
just as if the mode had been available all along.

This has to be done after every reboot (and possibly, I'm not sure,
every restart of X), so the obvious thing to do is to script it, and the
most straightforward way to make it get invoked at the right time in the
X bring-up process was to put that script in ~/.xinitrc.

The ~/.xinitrc I use is attached; please review and consider, but not
necessarily use wholesale or blindly. I have been using it successfully
for years, but it is not necessarily suitable for others' environments.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw
# Tell xrandr about the 2560x1600@60 resolution, and make it use that
TARGET_MODE_NAME=2560x1600

# if that resolution is already available, don't do anything
if (xrandr | grep "${TARGET_MODE_NAME}" > /dev/null) ; then
  # do nothing
  true
else 
  # Modeline generated by the command line:
  #$ cvt 2560 1600
  # can potentially be generated on-the-fly with:
  #$ cvt 2560 1600 60 | grep '\b2560\b' | cut -d ' ' -f 3-
  # but that's untested, and factoring it into this script would mean factoring the two resolution numbers out into separate variables (as inputs to TARGET_MODE_NAME and to that cvt pipeline), and that's not something I want to try right now
  xrandr --newmode "${TARGET_MODE_NAME}" 348.50  2560 2760 3032 3504  1600 1603 1609 1658 -hsync +vsync

  X_OUTPUT=$(xrandr | grep ' connected primary ' | cut -d ' ' -f 1)
  if [ -z "${X_OUTPUT}" ] ; then
    echo "xinitrc: xrandr failed to detect connected primary display, not adding modeline"
  else
    xrandr --addmode "${X_OUTPUT}" "${TARGET_MODE_NAME}"
    # TODO: Adjust the conditional logic so that the mode-change step gets run if the mode already exists, rather than only after it gets created
    # that could turn out to be as simple as moving that line outside of the conditionals...
    xrandr --output "${X_OUTPUT}" --mode "${TARGET_MODE_NAME}"
  fi
fi

## Kick off the system scripts which handle the rest, including bringing up the window manager
/etc/X11/xinit/xinitrc

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: