ladybird/Userland/Services/WindowServer/Screen.cpp

199 lines
7.4 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include "Screen.h"
#include "Compositor.h"
#include "Event.h"
#include "EventLoop.h"
#include "WindowManager.h"
#include <AK/Debug.h>
#include <Kernel/API/FB.h>
#include <Kernel/API/MousePacket.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
2018-10-10 16:12:38 +03:00
namespace WindowServer {
2018-10-10 16:12:38 +03:00
static Screen* s_the;
Screen& Screen::the()
2018-10-10 16:12:38 +03:00
{
VERIFY(s_the);
2018-10-10 16:12:38 +03:00
return *s_the;
}
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
Screen::Screen(unsigned desired_width, unsigned desired_height, int scale_factor)
2018-10-10 16:12:38 +03:00
{
VERIFY(!s_the);
2018-10-10 16:12:38 +03:00
s_the = this;
m_framebuffer_fd = open("/dev/fb0", O_RDWR | O_CLOEXEC);
if (m_framebuffer_fd < 0) {
perror("failed to open /dev/fb0");
VERIFY_NOT_REACHED();
}
if (fb_set_buffer(m_framebuffer_fd, 0) == 0) {
m_can_set_buffer = true;
}
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
set_resolution(desired_width, desired_height, scale_factor);
m_physical_cursor_location = physical_rect().center();
}
Screen::~Screen()
{
close(m_framebuffer_fd);
}
bool Screen::set_resolution(int width, int height, int new_scale_factor)
{
int new_physical_width = width * new_scale_factor;
int new_physical_height = height * new_scale_factor;
if (physical_width() == new_physical_width && physical_height() == new_physical_height) {
assert(scale_factor() != new_scale_factor);
on_change_resolution(m_pitch, physical_width(), physical_height(), new_scale_factor);
return true;
}
FBResolution physical_resolution { 0, (unsigned)new_physical_width, (unsigned)new_physical_height };
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
int rc = fb_set_resolution(m_framebuffer_fd, &physical_resolution);
dbgln_if(WSSCREEN_DEBUG, "fb_set_resolution() - return code {}", rc);
if (rc == 0) {
on_change_resolution(physical_resolution.pitch, physical_resolution.width, physical_resolution.height, new_scale_factor);
return true;
}
if (rc == -1) {
dbgln("Invalid resolution {}x{}", width, height);
on_change_resolution(physical_resolution.pitch, physical_resolution.width, physical_resolution.height, new_scale_factor);
return false;
}
VERIFY_NOT_REACHED();
}
void Screen::on_change_resolution(int pitch, int new_physical_width, int new_physical_height, int new_scale_factor)
{
if (physical_width() != new_physical_width || physical_height() != new_physical_height) {
if (m_framebuffer) {
size_t previous_size_in_bytes = m_size_in_bytes;
int rc = munmap(m_framebuffer, previous_size_in_bytes);
VERIFY(rc == 0);
}
int rc = fb_get_size_in_bytes(m_framebuffer_fd, &m_size_in_bytes);
VERIFY(rc == 0);
m_framebuffer = (Gfx::RGBA32*)mmap(nullptr, m_size_in_bytes, PROT_READ | PROT_WRITE, MAP_SHARED, m_framebuffer_fd, 0);
VERIFY(m_framebuffer && m_framebuffer != (void*)-1);
}
2018-10-10 16:12:38 +03:00
m_pitch = pitch;
m_width = new_physical_width / new_scale_factor;
m_height = new_physical_height / new_scale_factor;
m_scale_factor = new_scale_factor;
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
m_physical_cursor_location.constrain(physical_rect());
2018-10-10 16:12:38 +03:00
}
void Screen::set_buffer(int index)
{
VERIFY(m_can_set_buffer);
int rc = fb_set_buffer(m_framebuffer_fd, index);
VERIFY(rc == 0);
}
void Screen::set_acceleration_factor(double factor)
{
VERIFY(factor >= mouse_accel_min && factor <= mouse_accel_max);
m_acceleration_factor = factor;
}
void Screen::set_scroll_step_size(unsigned step_size)
{
VERIFY(step_size >= scroll_step_size_min);
m_scroll_step_size = step_size;
}
void Screen::on_receive_mouse_data(const MousePacket& packet)
{
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
auto prev_location = m_physical_cursor_location / m_scale_factor;
if (packet.is_relative) {
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
m_physical_cursor_location.move_by(packet.x * m_acceleration_factor, packet.y * m_acceleration_factor);
#if WSSCREEN_DEBUG
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
dbgln("Screen: New Relative mouse point @ {}", m_physical_cursor_location);
#endif
} else {
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
m_physical_cursor_location = { packet.x * physical_width() / 0xffff, packet.y * physical_height() / 0xffff };
#if WSSCREEN_DEBUG
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
dbgln("Screen: New Absolute mouse point @ {}", m_physical_cursor_location);
#endif
}
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
m_physical_cursor_location.constrain(physical_rect());
auto new_location = m_physical_cursor_location / m_scale_factor;
unsigned buttons = packet.buttons;
unsigned prev_buttons = m_mouse_button_state;
m_mouse_button_state = buttons;
unsigned changed_buttons = prev_buttons ^ buttons;
auto post_mousedown_or_mouseup_if_needed = [&](MouseButton button) {
if (!(changed_buttons & (unsigned)button))
return;
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
auto message = make<MouseEvent>(buttons & (unsigned)button ? Event::MouseDown : Event::MouseUp, new_location, buttons, button, m_modifiers);
Core::EventLoop::current().post_event(WindowManager::the(), move(message));
};
post_mousedown_or_mouseup_if_needed(MouseButton::Left);
post_mousedown_or_mouseup_if_needed(MouseButton::Right);
post_mousedown_or_mouseup_if_needed(MouseButton::Middle);
post_mousedown_or_mouseup_if_needed(MouseButton::Back);
post_mousedown_or_mouseup_if_needed(MouseButton::Forward);
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
if (new_location != prev_location) {
auto message = make<MouseEvent>(Event::MouseMove, new_location, buttons, MouseButton::None, m_modifiers);
if (WindowManager::the().dnd_client())
message->set_mime_data(WindowManager::the().dnd_mime_data());
Core::EventLoop::current().post_event(WindowManager::the(), move(message));
}
if (packet.z) {
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
auto message = make<MouseEvent>(Event::MouseWheel, new_location, buttons, MouseButton::None, m_modifiers, packet.z * m_scroll_step_size);
Core::EventLoop::current().post_event(WindowManager::the(), move(message));
}
WindowServer: Make HighDPI aware Almost all logic stays in "logical" (unscaled coordinates), which means the patch is small and things like DnD, window moving and resizing, menu handling, menuapplets, etc all work without changes. Screen knows about phyiscal coordinates and mouse handling internally is in physical coordinates (so that two 1 pixel movements in succession can translate to one 1 logical coordinate mouse movement -- only a single event is sent in this case, on the 2nd moved pixel). Compositor also knows about physical pixels for its backbuffers. This is a temporary state -- in a follow-up, I'll try to let Bitmaps know about their intrinsic scale, then Compositor won't have to know about pixels any longer. Most of Compositor's logic stays in view units, just blitting to and from back buffers and the cursor save buffer has to be done in pixels. The back buffer Painter gets a scale applied which transparently handles all drawing. (But since the backbuffer and cursor save buffer are also HighDPI, they currently need to be drawn using a hack temporary unscaled Painter object. This will also go away once Bitmaps know about their intrinsic scale.) With this, editing WindowServer.ini to say Width=800 Height=600 ScaleFactor=2 and booting brings up a fully-functional HighDPI UI. (Except for minimizing windows, which will crash the window server until #4932 is merged. And I didn't test the window switcher since the win-tab shortcut doesn't work on my system.) It's all pixel-scaled, but it looks pretty decent :^)
2021-01-15 18:58:55 +03:00
if (new_location != prev_location)
Compositor::the().invalidate_cursor();
}
void Screen::on_receive_keyboard_data(::KeyEvent kernel_event)
{
m_modifiers = kernel_event.modifiers();
auto message = make<KeyEvent>(kernel_event.is_press() ? Event::KeyDown : Event::KeyUp, kernel_event.key, kernel_event.code_point, kernel_event.modifiers(), kernel_event.scancode);
Core::EventLoop::current().post_event(WindowManager::the(), move(message));
}
}