Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • xserver xserver
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 922
    • Issues 922
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 120
    • Merge requests 120
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • xorgxorg
  • xserverxserver
  • Merge requests
  • !111

WIP: xwayland: Multi DPI support via max factor rescaling

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Roman Gilg requested to merge romangg/xserver:xwlScaling into master Jan 23, 2019
  • Overview 52
  • Commits 1
  • Pipelines 7
  • Changes 8

This patch attempts to resolve our XWayland multi dpi problem in a simple, yet effective way. More details about the technical solution are written down in the commit message of the attached commit.

Advantages of the approach are:

  • HiDPI aware X clients become multi DPI in a Wayland session with a single integer scale factor being set (for example GDK_SCALE=2), independent of number of Wayland scale factors and their divisibilities.
  • Small changes to XWayland.
  • The necessary coordinate transformation in the Wayland compositor is a simple division/multiplication with a single integer factor independent of X client and output it is on.
  • Full backwards compatibility to compositors not supporting this new functionality.
  • X clients which read out the current RandR resolution to set internal options (for example games) will not be limited artificially anymore by the logical size being smaller than the real resolution.

Disadvantages are:

  • In a mixed DPI setup a non-HiDPI-aware X client will look similarly tiny on all outputs, including LoDPI ones. This can be fixed for simple clients with https://keithp.com/blogs/window-scaling/
  • In a mixed DPI setup all XWayland client buffers on the LoDPI output must be downscaled by the compositor. Depending on the graphics pipeline in use this can be taxing.
  • Clients reading out RandR resolutions will see too large resolutions in comparison to the real mode for outputs with lower than maximum scale factor.
  • While the compositor only needs to do simple transformation of coordinates, it still needs to do it for all interaction between Wayland native clients and its internal logic with XWayland. Depending on the compositor code this might be difficult.

This patch has been tested successfully together with the following KWin patch in a KWin Wayland session: https://phabricator.kde.org/D18486

You can watch a demonstration here: https://youtu.be/a8HPS3LbCCg

Edited Jan 24, 2019 by Roman Gilg
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: xwlScaling