###### tags: `GNOME`
[GNOME Fractional Scaling Hackfest](https://wiki.gnome.org/Hackfests/FractionalScaling2017)
### Git branches
### jhbuild config for Ubuntu
* https://pastebin.ubuntu.com/24789597/ (change paths)
* It needs to build and install https://packages.debian.org/sid/libical2 manually on Ubuntu 16.04.
* If there are some errors like "'ltmain.sh' not found", running `libtoolize` in the git tree.
* If there is some problem when using `jhbuild sysdeps --install`, trying the patch on https://bugzilla.gnome.org/show_bug.cgi?id=778912.
* `jhbuild build gnome-shell mutter xserver`
* Execute gnome-shell manually under tty1
* `jhbuild run dbus-run-session gnome-shell --wayland --display-server >& log`
* Removing `fonts-noto-cjk` can shorten the starting time after build a lot.
* Alt-F2 to enter `debugexit` to leave gnome-shell
* `git clone https://github.com/jadahl/gnome-monitor-config`
`meson . build`
* `./build/src/gnome-monitor-config list`
* `./build/src/gnome-monitor-config set -L -p -M eDP-1 -s 2`
* `./build/src/gnome-monitor-config set -L -p -M eDP-1 -s 2 -L -x 1920 -M DP-1 -s 1`
* Executing `jhbuild make` under the git tree can install the package without committing the change.
* Got LOTS of HiDPI hardware (and setup an XPS 15 to run last GS)...
* Defining policies to chose which fracional value allow for scaling depending on scale
* Jonas worked in implementing the API to get the monitor scaling available for each monitor mode
* Jonas updated gnome-settings-daemon to work with the API changes
* Marco wrote an algorithm to pick the closest fractional levels close to integers that we can pick as logical size
* Fixed some bugs
* Got rid of scaling things at 3, and using 2 as scaling and downscaling everything.
* Looking in widgets that support floating scaling
![Do you like boards? We have a board](https://farm5.staticflickr.com/4269/34980195811_0f6e7f0753_z.jpg "Do you like boards? We have a board!")
*«Do you like boards? We have a board!»*
* Some discussion about handling clients in that are non-fractional
* Adapting gnome-control-center to support new `GetCurrentState` API
* Wrote scaling aware test clients to test sub-logical pixel down scaling (scale 1.5 monitor, scale 2 surface)
![Checking the scaling results...](https://farm5.staticflickr.com/4235/34968069082_355404564b_z.jpg "Checking the scaling results...")
* Researches on proper EDID parsing (serial is missing in many panels)
* Discussed how to identify monitors in a configuration if EDID is incomplete (e.g serial number collisions or lack of serial number)
* We'd use CONNECTOR+VENDOR+PRODUCT to identify a monitor when the serial number is useless
* We'd use VENDOR+PRODUCT+SERIAL if possible to allow not caring about what connector a monitor is connected to)
* Always store CONNECTOR+VENDOR+PRODUCT+SERIAL in configuration file
* Discussed automatic scale calculation from DPI with System76 (dmj_s76)
* System76 has done a lot of testing on hardware and have concluded that DPI <= 170 "absolutely must be 1x" (for laptop panels)
* They say: *«for general usability on laptops, we found you can get away with purely integer scaling. 1x scaling tends to be ideal about around 140dpi, and is usable up to about 210 dpi. From 210 dpi up to 350 dpi (centered on an ideal of 280 dpi) 2x scaling works».*
* Fixed screenshooting with scaled framebuffers
* Be more flexible in accepting floating numbers in the DBus mutter API
* Finished the implmentation of gnome-control-center ui and API update
* Analyzing issues causing glitches due to wrong damaged areas
* Some fixes to the control-center
* Setting up an XPS 13 for further testing
* Fixing gnome-control-center to get the preferred setting, and initied the work to use it (needs some more changes)
* FourDollars started the work on getting st-widgets areas to be painted with better scaling
* Some refactor of `CluterCanvas` and `StDrawingArea` to use resource-scale
* Fixing fullscreen animation clipping issue
* Fixed glitches caused by subpixel damage regions
* Fixed sub-(logical)-pixel positioning of cursor sprites
* Fix the wrong workspace thubmnail of the first seeing after changing the scale factor
* Fixed control center to use the preferred mode
* Fixed various precision loss issues causing configurations to be discarded
* Trying to define an algorithm with proper boundaries to get the optimal scale factor for HiDPI hardware
* Defining a [wiki](https://wiki.gnome.org/action/edit/Projects/GnomeShell/ScaleFactorTests) with the tested configurations and optimal scaling values
* ~~XWayland clients scaled to values < 1.0 thinks that they are located in a giantic X11 output, thus menus won't be moved accordingly or they won't maximize properly.~~
* ~~Mutter WM fixes~~
* XWayland clients resize from the top cause them to jump around
* Passing too precise floats for scaling values can lead to configuratio issues..
* Window moving back and forth using fractional scaling and `CLUTTER_PAINT=redraws`
* ~~Scale rounding problem (settings are not restored or applied from dbus):~~
* ~~`MetaLogicalMonitorConfig` scales approximately using the best value between the allowed ones~~
* ~~When apply -> Fix by dinfing the best available scale from `MetaMonitorMode`~~
* ~~Migrating monitor.xml configuration to the new format~~
* ~~Both in legacy and new configuration we need to give serial and monitor id priority over connector name~~
* ~~EDID parsing doesn't has the serial all the times... Checking if DisplayID is an option~~
* ~~Configurations for tiled monitors might fail, as we don't have the tiling information stored in the configuration~~
* When 'layout-mode' is 'logical-layout-mode', when there are monitors right of or below a scaled monitor, the configuration gets discarded as the position will be wrong.
* ~~a11y zoom is broken:~~
* ~~Pointer get lost~~
* Touch imput events goes... Who knows where!
* ~~Check if pointer is hidden in a11y zoomed mode because of scaled framebuffer~~
* ST widgets
* ~~Getting better result from st-drawing-area by moving scaling to clutter-actor~~
* ~~Notifications bubble text extents outside of bubble~~
* ~~Dock, dialogs...~~
* ~~Mutter background doesn't take care of proper resource scaling~~
* ~~Glitches on OpenGL cursor~~
* Update scaling values when we changes the gobal scaling factor
* X11 (XWayland clients):
* Multi-dpi support, so multiple clients with different scaling running in the same XWayland instance needs to communicate their scaling parameter in order to be properly drawn
* Mutter X11 window frame support (serverside decoration don't have a clue about the scaling we do)
* Auto-detect scale level (also at floating values)
* Use diferent methods in docked setups (detect them)
* Looking why the fullscren animation scales down and then up again the actor
* This is because in wayland we've immediate calls to `meta_window_make_fullscreen` and `meta_window_unmake_fullscreen` as soon as we request teh change (causing a `size-changed` signal emission), instead of only waiting for wayland confirming the change.
* ~~Control-center: fix scale slider when new monitor interface is disabled~~
* Avoid flickering when ony scaling is changed in mutter
* Consider allowing vendors to override default scaling factor using some system similiar to hwdb using data from EDID as identifier
* Wayland protocol improvements for fullscreen apps bypassing the scale (video players and games don't mind this)
* ~~GTK+ client support for `scaling > 2` (shadows are broken there are random crashes around).~~ [[patch](https://gitlab.gnome.org/GNOME/gtk/commit/29f36fe)]
* HW Cursor
* Glitches in the contro-center confirmation dialog when setting a different scaling (with another monitor plugged?) - Find a way to reproduce again ;-)
* Toolkit with fractional scaling suport (Qt) to draw at native size instead of scaling them down.
* Create a migration script that reads the gtk scaling-factor setting and UI settings and generates a monitors.xml using the users values (not to break the mutter auto scaling feature)
* ~~Dismiss the gtk-cursor size value~~