mirrors/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity.git synced 2025-01-24 10:22:05 -05:00
Code Issues Projects Releases Packages Wiki Activity
serenity/Kernel/Graphics/DisplayConnector.cpp

466 lines
22 KiB
C++
Raw Normal View History

Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
/*
* Copyright (c) 2022, Liav A. <liavalb@hotmail.co.il>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
#include <Kernel/FileSystem/SysFS/Subsystems/DeviceIdentifiers/CharacterDevicesDirectory.h>
#include <Kernel/FileSystem/SysFS/Subsystems/Devices/Graphics/DisplayConnector/DeviceDirectory.h>
#include <Kernel/FileSystem/SysFS/Subsystems/Devices/Graphics/DisplayConnector/Directory.h>
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
#include <Kernel/Graphics/DisplayConnector.h>
#include <Kernel/Graphics/GraphicsManagement.h>
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
#include <Kernel/Memory/MemoryManager.h>
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
#include <LibC/sys/ioctl_numbers.h>
namespace Kernel {
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
DisplayConnector::DisplayConnector(PhysicalAddress framebuffer_address, size_t framebuffer_resource_size, bool enable_write_combine_optimization)
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
: CharacterDevice(226, GraphicsManagement::the().allocate_minor_device_number())
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
, m_enable_write_combine_optimization(enable_write_combine_optimization)
, m_framebuffer_at_arbitrary_physical_range(false)
, m_framebuffer_address(framebuffer_address)
, m_framebuffer_resource_size(framebuffer_resource_size)
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
{
}
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
DisplayConnector::DisplayConnector(size_t framebuffer_resource_size, bool enable_write_combine_optimization)
: CharacterDevice(226, GraphicsManagement::the().allocate_minor_device_number())
, m_enable_write_combine_optimization(enable_write_combine_optimization)
, m_framebuffer_at_arbitrary_physical_range(true)
, m_framebuffer_address({})
, m_framebuffer_resource_size(framebuffer_resource_size)
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
{
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
}
Kernel: Simplify the File memory-mapping API Before this change, we had File::mmap() which did all the work of setting up a VMObject, and then creating a Region in the current process's address space. This patch simplifies the interface by removing the region part. Files now only have to return a suitable VMObject from vmobject_for_mmap(), and then sys$mmap() itself will take care of actually mapping it into the address space. This fixes an issue where we'd try to block on I/O (for inode metadata lookup) while holding the address space spinlock. It also reduces time spent holding the address space lock.
2022-08-23 18:51:18 +02:00
ErrorOr<NonnullLockRefPtr<Memory::VMObject>> DisplayConnector::vmobject_for_mmap(Process&, Memory::VirtualRange const&, u64& offset, bool)
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
{
VERIFY(m_shared_framebuffer_vmobject);
if (offset != 0)
return Error::from_errno(ENOTSUP);
Kernel: Simplify the File memory-mapping API Before this change, we had File::mmap() which did all the work of setting up a VMObject, and then creating a Region in the current process's address space. This patch simplifies the interface by removing the region part. Files now only have to return a suitable VMObject from vmobject_for_mmap(), and then sys$mmap() itself will take care of actually mapping it into the address space. This fixes an issue where we'd try to block on I/O (for inode metadata lookup) while holding the address space spinlock. It also reduces time spent holding the address space lock.
2022-08-23 18:51:18 +02:00
return *m_shared_framebuffer_vmobject;
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
}
ErrorOr<size_t> DisplayConnector::read(OpenFileDescription&, u64, UserOrKernelBuffer&, size_t)
{
return Error::from_errno(ENOTIMPL);
}
Kernel/Graphics: Drop support for the DisplayConnector write interface The WindowServer doesn't use this interface anymore and therefore it's not used by any userspace application, so let's remove this stale method to ensure we don't have to bother with it anymore.
2022-05-13 03:26:36 +03:00
ErrorOr<size_t> DisplayConnector::write(OpenFileDescription&, u64, UserOrKernelBuffer const&, size_t)
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
{
Kernel/Graphics: Drop support for the DisplayConnector write interface The WindowServer doesn't use this interface anymore and therefore it's not used by any userspace application, so let's remove this stale method to ensure we don't have to bother with it anymore.
2022-05-13 03:26:36 +03:00
return Error::from_errno(ENOTIMPL);
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
}
void DisplayConnector::will_be_destroyed()
{
GraphicsManagement::the().detach_display_connector({}, *this);
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
VERIFY(m_symlink_sysfs_component);
Kernel/Devices: Abstract SysFS Device add/remove methods more properly It is starting to get a little messy with how each device can try to add or remove itself to either /sys/dev/block or /sys/dev/char directories. To better do this, we introduce 4 virtual methods to take care of that, so until we ensure all nodes in /sys/dev/block and /sys/dev/char are actual symlinks, we allow the Device base class to call virtual methods upon insertion or before being destroying, so it add itself elegantly to either of these directories or remove itself when needed. For special cases where we need to create symlinks, we have two virtual methods to be called otherwise to do almost the same thing mentioned before, but to use symlinks instead.
2022-07-16 10:39:57 +03:00
before_will_be_destroyed_remove_symlink_from_device_identifier_directory();
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
m_symlink_sysfs_component.clear();
SysFSDisplayConnectorsDirectory::the().unplug({}, *m_sysfs_device_directory);
before_will_be_destroyed_remove_from_device_management();
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
}
void DisplayConnector::after_inserting()
{
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
after_inserting_add_to_device_management();
auto sysfs_display_connector_device_directory = DisplayConnectorSysFSDirectory::create(SysFSDisplayConnectorsDirectory::the(), *this);
m_sysfs_device_directory = sysfs_display_connector_device_directory;
SysFSDisplayConnectorsDirectory::the().plug({}, *sysfs_display_connector_device_directory);
VERIFY(!m_symlink_sysfs_component);
Kernel/SysFS: Fix parent directory hierarchy with symbolic links We should actually start counting from the parent directory and not from the symbolic link as it will represent a wrong count of hops from the actual mountpoint. The symlinks in /sys/dev/block and /sys/dev/char worked only by luck, because I have set it to the wrong parent directory which is the /sys/dev directory, so with the symlink it was 3 hops to /sys, together with the root directory, therefore, everything seemed to work. Now that the device symlinks in /sys/dev/block and /sys/dev/char are set to the right parent directory and we start measure hops from root directory with the parent directory of a symlink, everything seem to work correctly now.
2022-07-16 18:15:37 +03:00
auto sys_fs_component = MUST(SysFSSymbolicLinkDeviceComponent::try_create(SysFSCharacterDevicesDirectory::the(), *this, *m_sysfs_device_directory));
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
m_symlink_sysfs_component = sys_fs_component;
Kernel/Devices: Abstract SysFS Device add/remove methods more properly It is starting to get a little messy with how each device can try to add or remove itself to either /sys/dev/block or /sys/dev/char directories. To better do this, we introduce 4 virtual methods to take care of that, so until we ensure all nodes in /sys/dev/block and /sys/dev/char are actual symlinks, we allow the Device base class to call virtual methods upon insertion or before being destroying, so it add itself elegantly to either of these directories or remove itself when needed. For special cases where we need to create symlinks, we have two virtual methods to be called otherwise to do almost the same thing mentioned before, but to use symlinks instead.
2022-07-16 10:39:57 +03:00
after_inserting_add_symlink_to_device_identifier_directory();
Kernel/SysFS: Add exposing interface for DisplayConnectors Under normal conditions (when mounting SysFS in /sys), there will be a new directory in the /sys/devices directory called "graphics". For now, under that directory there will be only a sub-directory called "connectors" which will contain all DisplayConnectors' details, each in its own sub-directory too, distinguished in naming with its minor number. Therefore, /sys/devices/graphics/connectors/MINOR_NUMBER/ will contain: - General device attributes such as mutable_mode_setting_capable, double_buffering_capable, flush_support, partial_flush_support and refresh_rate_support. These values are exposed in the ioctl interface of the DisplayConnector class too, but these can be useful later on for command line utilities that want/need to expose these basic settings. - The EDID blob, simply named "edid". This will help userspace to fetch the edid without the need of using the ioctl interface later on.
2022-07-16 08:08:53 +03:00
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
auto rounded_size = MUST(Memory::page_round_up(m_framebuffer_resource_size));
if (!m_framebuffer_at_arbitrary_physical_range) {
VERIFY(m_framebuffer_address.value().page_base() == m_framebuffer_address.value());
m_shared_framebuffer_vmobject = MUST(Memory::SharedFramebufferVMObject::try_create_for_physical_range(m_framebuffer_address.value(), rounded_size));
m_framebuffer_region = MUST(MM.allocate_kernel_region(m_framebuffer_address.value().page_base(), rounded_size, "Framebuffer"sv, Memory::Region::Access::ReadWrite));
} else {
m_shared_framebuffer_vmobject = MUST(Memory::SharedFramebufferVMObject::try_create_at_arbitrary_physical_range(rounded_size));
m_framebuffer_region = MUST(MM.allocate_kernel_region_with_vmobject(m_shared_framebuffer_vmobject->real_writes_framebuffer_vmobject(), rounded_size, "Framebuffer"sv, Memory::Region::Access::ReadWrite));
}
m_framebuffer_data = m_framebuffer_region->vaddr().as_ptr();
m_fake_writes_framebuffer_region = MUST(MM.allocate_kernel_region_with_vmobject(m_shared_framebuffer_vmobject->fake_writes_framebuffer_vmobject(), rounded_size, "Fake Writes Framebuffer"sv, Memory::Region::Access::ReadWrite));
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
GraphicsManagement::the().attach_new_display_connector({}, *this);
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
if (m_enable_write_combine_optimization) {
[[maybe_unused]] auto result = m_framebuffer_region->set_write_combine(true);
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
}
bool DisplayConnector::console_mode() const
{
VERIFY(m_control_lock.is_locked());
return m_console_mode;
}
void DisplayConnector::set_display_mode(Badge<GraphicsManagement>, DisplayMode mode)
{
SpinlockLocker locker(m_control_lock);
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
Kernel: Force y offset 0 when switching between console & graphics modes This fixes a weird bug that when sometimes a user tried to switch to console mode, the screen was frozen on graphics mode. After a hour of debugging this, it became apparent that the problem was that we left the y offset of the bochs graphics device in an invalid state, so it was not zero because the WindowServer changed it, and the framebuffer console code is not aware of horizontal and vertical offsets of the framebuffer screen, leading to the problem that the framebuffer console updates the first framebuffer (y offset = 0), but hardware was indicated to show the second framebuffer (y offset = first framebuffer height). Therefore, when doing a switch between these modes, always set the y offset to be zero.
2022-05-06 14:58:55 +03:00
{
SpinlockLocker locker(m_modeset_lock);
[[maybe_unused]] auto result = set_y_offset(0);
}
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
m_console_mode = mode == DisplayMode::Console ? true : false;
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
if (m_console_mode) {
VERIFY(m_framebuffer_region->size() == m_fake_writes_framebuffer_region->size());
memcpy(m_fake_writes_framebuffer_region->vaddr().as_ptr(), m_framebuffer_region->vaddr().as_ptr(), m_framebuffer_region->size());
m_shared_framebuffer_vmobject->switch_to_fake_sink_framebuffer_writes({});
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
enable_console();
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
} else {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
disable_console();
Kernel/Graphics: Bring back the mmap interface for DisplayConnectors The mmap interface was removed when we introduced the DisplayConnector class, as it was quite unsafe to use and didn't handle switching between graphical and text modes safely. By using the SharedFramebufferVMObject, we are able to elegantly coordinate the switch by remapping the attached mmap'ed-Memory::Region(s) with different mappings, therefore, keeping WindowServer to think that the mappings it has are still valid, while they are going to a different physical range until we are back to the graphical mode (after a switch from text mode). Most drivers take advantage of the fact that we know where is the actual framebuffer in physical memory space, the SharedFramebufferVMObject is created with that information. However, the VirtIO driver is different in that aspect, because it relies on DMA transactions to show graphics on the framebuffer, so the SharedFramebufferVMObject is created with that mindset to support the arbitrary framebuffer location in physical memory space.
2022-05-13 03:23:13 +03:00
m_shared_framebuffer_vmobject->switch_to_real_framebuffer_writes({});
VERIFY(m_framebuffer_region->size() == m_fake_writes_framebuffer_region->size());
memcpy(m_framebuffer_region->vaddr().as_ptr(), m_fake_writes_framebuffer_region->vaddr().as_ptr(), m_framebuffer_region->size());
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
}
Kernel/Graphics: Ensure VMWare and VirtualBox EDIDs have manufacturer ID
2022-06-10 22:33:07 +03:00
ErrorOr<void> DisplayConnector::initialize_edid_for_generic_monitor(Optional<Array<u8, 3>> possible_manufacturer_id_string)
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
{
Kernel/Graphics: Ensure VMWare and VirtualBox EDIDs have manufacturer ID
2022-06-10 22:33:07 +03:00
u8 raw_manufacturer_id[2] = { 0x0, 0x0 };
if (possible_manufacturer_id_string.has_value()) {
Array<u8, 3> manufacturer_id_string = possible_manufacturer_id_string.release_value();
u8 byte1 = (((static_cast<u8>(manufacturer_id_string[0]) - '@') & 0x1f) << 2) | (((static_cast<u8>(manufacturer_id_string[1]) - '@') >> 3) & 3);
u8 byte2 = ((static_cast<u8>(manufacturer_id_string[2]) - '@') & 0x1f) | (((static_cast<u8>(manufacturer_id_string[1]) - '@') << 5) & 0xe0);
Array<u8, 2> manufacturer_id_string_packed_bytes = { byte1, byte2 };
raw_manufacturer_id[0] = manufacturer_id_string_packed_bytes[1];
raw_manufacturer_id[1] = manufacturer_id_string_packed_bytes[0];
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
Array<u8, 128> virtual_monitor_edid = {
0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, /* header */
Kernel/Graphics: Ensure VMWare and VirtualBox EDIDs have manufacturer ID
2022-06-10 22:33:07 +03:00
raw_manufacturer_id[1], raw_manufacturer_id[0], /* manufacturer */
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
0x00, 0x00, /* product code */
0x00, 0x00, 0x00, 0x00, /* serial number goes here */
0x01, /* week of manufacture */
0x00, /* year of manufacture */
0x01, 0x03, /* EDID version */
0x80, /* capabilities - digital */
0x00, /* horiz. res in cm, zero for projectors */
0x00, /* vert. res in cm */
0x78, /* display gamma (120 == 2.2). */
0xEE, /* features (standby, suspend, off, RGB, std */
/* colour space, preferred timing mode) */
0xEE, 0x91, 0xA3, 0x54, 0x4C, 0x99, 0x26, 0x0F, 0x50, 0x54,
/* chromaticity for standard colour space. */
0x00, 0x00, 0x00, /* no default timings */
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01, 0x01,
0x01, 0x01, 0x01, 0x01, /* no standard timings */
0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x06, 0x00, 0x02, 0x02,
0x02, 0x02,
/* descriptor block 1 goes below */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* descriptor block 2, monitor ranges */
0x00, 0x00, 0x00, 0xFD, 0x00,
0x00, 0xC8, 0x00, 0xC8, 0x64, 0x00, 0x0A, 0x20, 0x20, 0x20,
0x20, 0x20,
/* 0-200Hz vertical, 0-200KHz horizontal, 1000MHz pixel clock */
0x20,
/* descriptor block 3, monitor name */
0x00, 0x00, 0x00, 0xFC, 0x00,
'G', 'e', 'n', 'e', 'r', 'i', 'c', 'S', 'c', 'r', 'e', 'e', 'n',
/* descriptor block 4: dummy data */
0x00, 0x00, 0x00, 0x10, 0x00,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20,
0x00, /* number of extensions */
0x00 /* checksum goes here */
};
Kernel/Graphics: Ensure generic EDID always has correct checksum
2022-06-10 22:36:43 +03:00
// Note: Fix checksum to avoid warnings about checksum mismatch.
size_t checksum = 0;
// Note: Read all 127 bytes to add them to the checksum. Byte 128 is zeroed so
// we could technically add it to the sum result, but it could lead to an error if it contained
// a non-zero value, so we are not using it.
for (size_t index = 0; index < sizeof(virtual_monitor_edid) - 1; index++)
checksum += virtual_monitor_edid[index];
virtual_monitor_edid[127] = 0x100 - checksum;
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
set_edid_bytes(virtual_monitor_edid);
return {};
}
void DisplayConnector::set_edid_bytes(Array<u8, 128> const& edid_bytes)
{
memcpy((u8*)m_edid_bytes, edid_bytes.data(), sizeof(m_edid_bytes));
if (auto parsed_edid = EDID::Parser::from_bytes({ m_edid_bytes, sizeof(m_edid_bytes) }); !parsed_edid.is_error()) {
m_edid_parser = parsed_edid.release_value();
m_edid_valid = true;
} else {
dmesgln("DisplayConnector: Print offending EDID");
for (size_t x = 0; x < 128; x = x + 16) {
dmesgln("{:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x} {:02x}",
m_edid_bytes[x], m_edid_bytes[x + 1], m_edid_bytes[x + 2], m_edid_bytes[x + 3],
m_edid_bytes[x + 4], m_edid_bytes[x + 5], m_edid_bytes[x + 6], m_edid_bytes[x + 7],
m_edid_bytes[x + 8], m_edid_bytes[x + 9], m_edid_bytes[x + 10], m_edid_bytes[x + 11],
m_edid_bytes[x + 12], m_edid_bytes[x + 13], m_edid_bytes[x + 14], m_edid_bytes[x + 15]);
}
dmesgln("DisplayConnector: Parsing EDID failed: {}", parsed_edid.error());
}
}
ErrorOr<void> DisplayConnector::flush_rectangle(size_t, FBRect const&)
{
return Error::from_errno(ENOTSUP);
}
DisplayConnector::ModeSetting DisplayConnector::current_mode_setting() const
{
SpinlockLocker locker(m_modeset_lock);
return m_current_mode_setting;
}
ErrorOr<ByteBuffer> DisplayConnector::get_edid() const
{
if (!m_edid_valid)
return Error::from_errno(ENOTIMPL);
return ByteBuffer::copy(m_edid_bytes, sizeof(m_edid_bytes));
}
Kernel+Userland: Add ioctl to set process ownership of DisplayConnector Now that the infrastructure of the Graphics subsystem is quite stable, it is time to try to fix a long-standing problem, which is the lack of locking on display connector devices. Reading and writing from multiple processes to a framebuffer controlled by the display connector is not a huge problem - it could be solved with POSIX locking. The real problem is some program that will try to do ioctl operations on a display connector without the WindowServer being aware of that which can lead to very bad situations, for example - assuming a framebuffer is encoded at a known resolution and certain display timings, but another process changed the ModeSetting of the display connector, leading to inconsistency on the properties of the current ModeSetting. To solve this, there's a new "master" ioctl to take "ownership" and another one to release that ownership of a display connector device. To ensure we will not hold a Process object forever just because it has an ownership over a display connector, we hold it with a weak reference, and if the process is gone, someone else can take an ownership.
2022-06-10 14:16:28 +03:00
struct GraphicsIOCtlChecker {
unsigned ioctl_number;
StringView name;
bool requires_ownership { false };
};
static constexpr GraphicsIOCtlChecker s_checkers[] = {
{ GRAPHICS_IOCTL_GET_PROPERTIES, "GRAPHICS_IOCTL_GET_PROPERTIES"sv, false },
{ GRAPHICS_IOCTL_SET_HEAD_VERTICAL_OFFSET_BUFFER, "GRAPHICS_IOCTL_SET_HEAD_VERTICAL_OFFSET_BUFFER"sv, true },
{ GRAPHICS_IOCTL_GET_HEAD_VERTICAL_OFFSET_BUFFER, "GRAPHICS_IOCTL_GET_HEAD_VERTICAL_OFFSET_BUFFER"sv, false },
{ GRAPHICS_IOCTL_FLUSH_HEAD_BUFFERS, "GRAPHICS_IOCTL_FLUSH_HEAD_BUFFERS"sv, true },
{ GRAPHICS_IOCTL_FLUSH_HEAD, "GRAPHICS_IOCTL_FLUSH_HEAD"sv, true },
{ GRAPHICS_IOCTL_SET_HEAD_MODE_SETTING, "GRAPHICS_IOCTL_SET_HEAD_MODE_SETTING"sv, true },
{ GRAPHICS_IOCTL_GET_HEAD_MODE_SETTING, "GRAPHICS_IOCTL_GET_HEAD_MODE_SETTING"sv, false },
{ GRAPHICS_IOCTL_SET_SAFE_HEAD_MODE_SETTING, "GRAPHICS_IOCTL_SET_SAFE_HEAD_MODE_SETTING"sv, true },
{ GRAPHICS_IOCTL_SET_RESPONSIBLE, "GRAPHICS_IOCTL_SET_RESPONSIBLE"sv, false },
{ GRAPHICS_IOCTL_UNSET_RESPONSIBLE, "GRAPHICS_IOCTL_UNSET_RESPONSIBLE"sv, true },
};
static StringView ioctl_to_stringview(unsigned request)
{
for (auto& checker : s_checkers) {
if (checker.ioctl_number == request)
return checker.name;
}
VERIFY_NOT_REACHED();
}
bool DisplayConnector::ioctl_requires_ownership(unsigned request) const
{
for (auto& checker : s_checkers) {
if (checker.ioctl_number == request)
return checker.requires_ownership;
}
VERIFY_NOT_REACHED();
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
ErrorOr<void> DisplayConnector::ioctl(OpenFileDescription&, unsigned request, Userspace<void*> arg)
{
Kernel+Userland: Remove GRAPHICS_IOCTL_GET_HEAD_EDID ioctl We are able to read the EDID from SysFS, therefore there's no need to provide this ioctl on a DisplayConnector anymore. Also, now we can simply require the video pledge to be set before doing any ioctl on a DisplayConnector.
2022-07-16 08:38:18 +03:00
TRY(Process::current().require_promise(Pledge::video));
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
Kernel+Userland: Add ioctl to set process ownership of DisplayConnector Now that the infrastructure of the Graphics subsystem is quite stable, it is time to try to fix a long-standing problem, which is the lack of locking on display connector devices. Reading and writing from multiple processes to a framebuffer controlled by the display connector is not a huge problem - it could be solved with POSIX locking. The real problem is some program that will try to do ioctl operations on a display connector without the WindowServer being aware of that which can lead to very bad situations, for example - assuming a framebuffer is encoded at a known resolution and certain display timings, but another process changed the ModeSetting of the display connector, leading to inconsistency on the properties of the current ModeSetting. To solve this, there's a new "master" ioctl to take "ownership" and another one to release that ownership of a display connector device. To ensure we will not hold a Process object forever just because it has an ownership over a display connector, we hold it with a weak reference, and if the process is gone, someone else can take an ownership.
2022-06-10 14:16:28 +03:00
// Note: We only allow to set responsibility on a DisplayConnector,
// get the current ModeSetting or the hardware framebuffer properties without the
// need of having an established responsibility on a DisplayConnector.
if (ioctl_requires_ownership(request)) {
auto process = m_responsible_process.strong_ref();
if (!process || process.ptr() != &Process::current()) {
dbgln("DisplayConnector::ioctl: {} requires ownership over the device", ioctl_to_stringview(request));
return Error::from_errno(EPERM);
}
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
switch (request) {
Kernel+Userland: Add ioctl to set process ownership of DisplayConnector Now that the infrastructure of the Graphics subsystem is quite stable, it is time to try to fix a long-standing problem, which is the lack of locking on display connector devices. Reading and writing from multiple processes to a framebuffer controlled by the display connector is not a huge problem - it could be solved with POSIX locking. The real problem is some program that will try to do ioctl operations on a display connector without the WindowServer being aware of that which can lead to very bad situations, for example - assuming a framebuffer is encoded at a known resolution and certain display timings, but another process changed the ModeSetting of the display connector, leading to inconsistency on the properties of the current ModeSetting. To solve this, there's a new "master" ioctl to take "ownership" and another one to release that ownership of a display connector device. To ensure we will not hold a Process object forever just because it has an ownership over a display connector, we hold it with a weak reference, and if the process is gone, someone else can take an ownership.
2022-06-10 14:16:28 +03:00
case GRAPHICS_IOCTL_SET_RESPONSIBLE: {
SpinlockLocker locker(m_responsible_process_lock);
auto process = m_responsible_process.strong_ref();
// Note: If there's already a process being responsible, just return an error.
// We could technically return 0 if the the requesting process is already
// was set to be responsible for this DisplayConnector, but it servicing no
// no good purpose and should be considered a bug if this happens anyway.
if (process)
return Error::from_errno(EPERM);
m_responsible_process = Process::current();
return {};
}
case GRAPHICS_IOCTL_UNSET_RESPONSIBLE: {
SpinlockLocker locker(m_responsible_process_lock);
auto process = m_responsible_process.strong_ref();
if (!process)
return Error::from_errno(ESRCH);
if (process.ptr() != &Process::current())
return Error::from_errno(EPERM);
m_responsible_process.clear();
return {};
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_GET_PROPERTIES: {
Kernel+Userland: Provide bytes count for a DisplayConnector framebuffer This value will be used later on by WindowServer to reject resolutions that will request a mapping that will overflow the hardware framebuffer max length.
2022-09-24 16:55:46 +03:00
VERIFY(m_shared_framebuffer_vmobject);
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 14:54:46 +03:00
auto user_properties = static_ptr_cast<GraphicsConnectorProperties*>(arg);
GraphicsConnectorProperties properties {};
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
properties.flushing_support = flush_support();
properties.doublebuffer_support = double_framebuffering_capable();
properties.partial_flushing_support = partial_flush_support();
properties.refresh_rate_support = refresh_rate_support();
Kernel+Userland: Provide bytes count for a DisplayConnector framebuffer This value will be used later on by WindowServer to reject resolutions that will request a mapping that will overflow the hardware framebuffer max length.
2022-09-24 16:55:46 +03:00
properties.max_buffer_bytes = m_shared_framebuffer_vmobject->size();
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
return copy_to_user(user_properties, &properties);
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_GET_HEAD_MODE_SETTING: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 14:54:46 +03:00
auto user_head_mode_setting = static_ptr_cast<GraphicsHeadModeSetting*>(arg);
GraphicsHeadModeSetting head_mode_setting {};
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
TRY(copy_from_user(&head_mode_setting, user_head_mode_setting));
{
SpinlockLocker control_locker(m_control_lock);
head_mode_setting.horizontal_stride = m_current_mode_setting.horizontal_stride;
head_mode_setting.pixel_clock_in_khz = m_current_mode_setting.pixel_clock_in_khz;
head_mode_setting.horizontal_active = m_current_mode_setting.horizontal_active;
head_mode_setting.horizontal_front_porch_pixels = m_current_mode_setting.horizontal_front_porch_pixels;
head_mode_setting.horizontal_sync_time_pixels = m_current_mode_setting.horizontal_sync_time_pixels;
head_mode_setting.horizontal_blank_pixels = m_current_mode_setting.horizontal_blank_pixels;
head_mode_setting.vertical_active = m_current_mode_setting.vertical_active;
head_mode_setting.vertical_front_porch_lines = m_current_mode_setting.vertical_front_porch_lines;
head_mode_setting.vertical_sync_time_lines = m_current_mode_setting.vertical_sync_time_lines;
head_mode_setting.vertical_blank_lines = m_current_mode_setting.vertical_blank_lines;
head_mode_setting.horizontal_offset = m_current_mode_setting.horizontal_offset;
head_mode_setting.vertical_offset = m_current_mode_setting.vertical_offset;
}
return copy_to_user(user_head_mode_setting, &head_mode_setting);
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_SET_HEAD_MODE_SETTING: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 14:54:46 +03:00
auto user_mode_setting = static_ptr_cast<GraphicsHeadModeSetting const*>(arg);
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
auto head_mode_setting = TRY(copy_typed_from_user(user_mode_setting));
if (head_mode_setting.horizontal_stride < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.pixel_clock_in_khz < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.horizontal_active < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.horizontal_front_porch_pixels < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.horizontal_sync_time_pixels < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.horizontal_blank_pixels < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.vertical_active < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.vertical_front_porch_lines < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.vertical_sync_time_lines < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.vertical_blank_lines < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.horizontal_offset < 0)
return Error::from_errno(EINVAL);
if (head_mode_setting.vertical_offset < 0)
return Error::from_errno(EINVAL);
{
SpinlockLocker control_locker(m_control_lock);
ModeSetting requested_mode_setting;
requested_mode_setting.horizontal_stride = 0;
requested_mode_setting.pixel_clock_in_khz = head_mode_setting.pixel_clock_in_khz;
requested_mode_setting.horizontal_active = head_mode_setting.horizontal_active;
requested_mode_setting.horizontal_front_porch_pixels = head_mode_setting.horizontal_front_porch_pixels;
requested_mode_setting.horizontal_sync_time_pixels = head_mode_setting.horizontal_sync_time_pixels;
requested_mode_setting.horizontal_blank_pixels = head_mode_setting.horizontal_blank_pixels;
requested_mode_setting.vertical_active = head_mode_setting.vertical_active;
requested_mode_setting.vertical_front_porch_lines = head_mode_setting.vertical_front_porch_lines;
requested_mode_setting.vertical_sync_time_lines = head_mode_setting.vertical_sync_time_lines;
requested_mode_setting.vertical_blank_lines = head_mode_setting.vertical_blank_lines;
requested_mode_setting.horizontal_offset = head_mode_setting.horizontal_offset;
requested_mode_setting.vertical_offset = head_mode_setting.vertical_offset;
TRY(set_mode_setting(requested_mode_setting));
}
return {};
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_SET_SAFE_HEAD_MODE_SETTING: {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
SpinlockLocker control_locker(m_control_lock);
TRY(set_safe_mode_setting());
return {};
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_SET_HEAD_VERTICAL_OFFSET_BUFFER: {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
// FIXME: We silently ignore the request if we are in console mode.
// WindowServer is not ready yet to handle errors such as EBUSY currently.
SpinlockLocker control_locker(m_control_lock);
if (console_mode()) {
return {};
}
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 14:54:46 +03:00
auto user_head_vertical_buffer_offset = static_ptr_cast<GraphicsHeadVerticalOffset const*>(arg);
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
auto head_vertical_buffer_offset = TRY(copy_typed_from_user(user_head_vertical_buffer_offset));
SpinlockLocker locker(m_modeset_lock);
if (head_vertical_buffer_offset.offsetted < 0 || head_vertical_buffer_offset.offsetted > 1)
return Error::from_errno(EINVAL);
TRY(set_y_offset(head_vertical_buffer_offset.offsetted == 0 ? 0 : m_current_mode_setting.vertical_active));
if (head_vertical_buffer_offset.offsetted == 0)
m_vertical_offsetted = false;
else
m_vertical_offsetted = true;
return {};
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_GET_HEAD_VERTICAL_OFFSET_BUFFER: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 14:54:46 +03:00
auto user_head_vertical_buffer_offset = static_ptr_cast<GraphicsHeadVerticalOffset*>(arg);
GraphicsHeadVerticalOffset head_vertical_buffer_offset {};
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
TRY(copy_from_user(&head_vertical_buffer_offset, user_head_vertical_buffer_offset));
head_vertical_buffer_offset.offsetted = m_vertical_offsetted;
return copy_to_user(user_head_vertical_buffer_offset, &head_vertical_buffer_offset);
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_FLUSH_HEAD_BUFFERS: {
Kernel/Graphics: Implement basic support for VMWare SVGA adapter
2022-03-18 16:46:55 +02:00
if (console_mode())
return {};
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
if (!partial_flush_support())
return Error::from_errno(ENOTSUP);
MutexLocker locker(m_flushing_lock);
auto user_flush_rects = static_ptr_cast<FBFlushRects const*>(arg);
auto flush_rects = TRY(copy_typed_from_user(user_flush_rects));
if (Checked<unsigned>::multiplication_would_overflow(flush_rects.count, sizeof(FBRect)))
return Error::from_errno(EFAULT);
if (flush_rects.count > 0) {
for (unsigned i = 0; i < flush_rects.count; i++) {
FBRect user_dirty_rect;
TRY(copy_from_user(&user_dirty_rect, &flush_rects.rects[i]));
{
SpinlockLocker control_locker(m_control_lock);
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 13:56:29 +03:00
if (console_mode()) {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
return {};
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 13:56:29 +03:00
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
TRY(flush_rectangle(flush_rects.buffer_index, user_dirty_rect));
}
}
}
return {};
};
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 14:49:51 +03:00
case GRAPHICS_IOCTL_FLUSH_HEAD: {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
// FIXME: We silently ignore the request if we are in console mode.
// WindowServer is not ready yet to handle errors such as EBUSY currently.
MutexLocker locker(m_flushing_lock);
SpinlockLocker control_locker(m_control_lock);
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 13:56:29 +03:00
if (console_mode()) {
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
return {};
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 13:56:29 +03:00
}
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
if (!flush_support())
return Error::from_errno(ENOTSUP);
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 13:56:29 +03:00
Kernel/Graphics: Introduce the DisplayConnector class The DisplayConnector class is meant to replace the FramebufferDevice class. The advantage of this class over the FramebufferDevice class is: 1. It removes the mmap interface entirely. This interface is unsafe, as multiple processes could try to use it, and when switching to and from text console mode, there's no "good" way to revoke a memory mapping from this interface, let alone when there are multiple processes that call this interface. Therefore, in the DisplayConnector class there's no implementation for this method at all. 2. The class uses a new real-world structure called ModeSetting, which takes into account the fact that real hardware requires more than width, height and pitch settings to mode-set the display resolution. 3. The class assumes all instances should supply some sort of EDID, so it facilitates such mechanism to do so. Even if a given driver does not know what is the actual EDID, it will ask to create default-generic EDID blob. 3. This class shifts the responsibilies of switching between console mode and graphical mode from a GraphicsAdapter to the DisplayConnector class, so when doing the switch, the GraphicsManagement code actually asks each DisplayConnector object to do the switch and doesn't rely on the GraphicsAdapter objects at all.
2022-04-29 12:44:46 +03:00
TRY(flush_first_surface());
return {};
}
}
return EINVAL;
}
}
Reference in a new issue Copy permalink