<div dir="ltr"><div>Hello Dave</div><div><br></div>Let's cool down the discussion a bit and try to work out a solution.<div><br></div><div>To summarize the facts, your decision implies that the probability of merging DAL/DC into the mainline Linux kernel the next year (2017) has become extremely low.</div><div><br></div><div>In essence, the strategy you are implicitly proposing is to move away from a software architecture which looks like this:</div><div><br></div><div>  APPLICATION</div><div>  USERSPACE DRIVERS (OPENGL, XSERVER)</div><div>  ----</div><div>  HAL/DC IN AMDGPU.KO (FREESYNC, etc)</div><div>  LINUX KERNEL SERVICES</div><div>  HARDWARE</div><div><br></div><div>towards a software architecture looking like this:</div><div><br></div><div><div>  APPLICATION</div><div>  USERSPACE DRIVERS (OPENGL, XSERVER)</div><div>  USERSPACE HAL/DC IMPLEMENTATION (FREESYNC, etc)</div><div>  ----</div><div>  AMDGPU.KO</div><div>  LINUX KERNEL SERVICES</div><div>  HARDWARE</div></div><div><br></div><div>For the future of Linux the latter basically means that the Linux kernel won't be initializing display resolution (modesetting) when the machine is booting. The initial modesetting will be performed by a user-space executable launched by openrc/systemd/etc as soon as possible. Launching the userspace modesetting executable will be among the first actions of openrc/systemd/etc.</div><div><br></div><div>Note that during the 90-ties Linux-based systems _already_ had the xserver responsible for modesetting. Linux gradually moved away from the 90-ties software architecture towards an in-kernel modesetting architecture.</div><div><br></div><div>A citation from <a href="https://en.wikipedia.org/wiki/X.Org_Server">https://en.wikipedia.org/wiki/X.Org_Server</a> is in order here: "In ancient times, the mode-setting was done by some x-server graphics device drivers specific to some video controller/graphics card. To this mode-setting functionality, additional support for 2D acceleration was added when such became available with various GPUs. The mode-setting functionality was moved into the DRM and is being exposed through an DRM mode-setting interface, the new approach being called "kernel mode-setting" (KMS)."</div><div><br></div><div>The underlying simple hard fact behind the transition from 90-ties user-modesetting to kernel-modesetting is that most Linux users prefer to see a single display mode initialization which persists from machine boot to machine shutdown. In the near future, the combination of the following four factors:</div><div><br></div><div>1. General availability of 144Hz displays<br></div><div>2. Up/down-scaling of fullscreen OpenGL/Vulkan apps (virtual display resolution)</div><div>3. Per-frame monitor refresh rate adjustment (freesync, g-sync)</div><div>4. Competition of innovations</div><div><br></div><div>will render non-native monitor resolutions and non-native physical framerates completely obsolete. (3) is a transient phenomenon which will be later superseded by further developments in the field of (1) towards emergence of virtual refresh rates.</div><div><br></div><div><div>Jan</div></div></div>