dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Kernel/Devices/GPU/DisplayConnector.cpp

519 lines
25 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 06:44:46 -03:00
/*
* Copyright (c) 2022, Liav A. <liavalb@hotmail.co.il>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
Kernel+Userland: Move LibC/sys/ioctl_numbers to Kernel/API/Ioctl.h This header has always been fundamentally a Kernel API file. Move it where it belongs. Include it directly in Kernel files, and make Userland applications include it via sys/ioctl.h rather than directly.
2023-01-07 17:52:06 -03:00
#include <Kernel/API/Ioctl.h>
Kernel: Move all Graphics-related code into Devices/GPU directory Like the HID, Audio and Storage subsystem, the Graphics subsystem (which handles GPUs technically) exposes unix device files (typically in /dev). To ensure consistency across the repository, move all related files to a new directory under Kernel/Devices called "GPU". Also remove the redundant "GPU" word from the VirtIO driver directory, and the word "Graphics" from GraphicsManagement.{h,cpp} filenames.
2023-06-03 08:47:47 -03:00
#include <Kernel/Devices/GPU/DisplayConnector.h>
#include <Kernel/Devices/GPU/Management.h>
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 02: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: 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-12 21: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 06:44:46 -03:00
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-12 21: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 06: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-12 21: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 06: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-12 21: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 06: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-12 21: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 13:51:18 -03: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-12 21: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 13:51:18 -03: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 06: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-12 21: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 06: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-12 21: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 06: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 02:08:53 -03:00
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
// NOTE: We check if m_symlink_sysfs_component is not null, because if we failed
// at some point in DisplayConnector::after_inserting(), then that method will tear down
// the object internal members safely, so we don't want to do it again here.
if (m_symlink_sysfs_component) {
before_will_be_destroyed_remove_symlink_from_device_identifier_directory();
m_symlink_sysfs_component.clear();
}
// NOTE: We check if m_sysfs_device_directory is not null, because if we failed
// at some point in DisplayConnector::after_inserting(), then that method will tear down
// the object internal members safely, so we don't want to do it again here.
if (m_sysfs_device_directory) {
SysFSDisplayConnectorsDirectory::the().unplug({}, *m_sysfs_device_directory);
m_sysfs_device_directory.clear();
}
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 04:39:57 -03:00
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 02:08:53 -03:00
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 06:44:46 -03:00
}
Kernel/Graphics: Allocate 16 MiB framebuffer if failed allocating larger We try our best to ensure a DisplayConnector initialization succeeds, and this makes the Intel driver to work again, because if we can't allocate a Region for the whole PCI BAR mapped region, then we will try to allocate a Region with 16 MiB window size, so it doesn't eat the entire Kernel-allocated virtual memory space.
2022-12-22 06:35:35 -03:00
ErrorOr<void> DisplayConnector::allocate_framebuffer_resources(size_t rounded_size)
{
VERIFY((rounded_size % PAGE_SIZE) == 0);
if (!m_framebuffer_at_arbitrary_physical_range) {
VERIFY(m_framebuffer_address.value().page_base() == m_framebuffer_address.value());
m_shared_framebuffer_vmobject = TRY(Memory::SharedFramebufferVMObject::try_create_for_physical_range(m_framebuffer_address.value(), rounded_size));
m_framebuffer_region = TRY(MM.allocate_kernel_region(m_framebuffer_address.value().page_base(), rounded_size, "Framebuffer"sv, Memory::Region::Access::ReadWrite));
} else {
m_shared_framebuffer_vmobject = TRY(Memory::SharedFramebufferVMObject::try_create_at_arbitrary_physical_range(rounded_size));
m_framebuffer_region = TRY(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 = TRY(MM.allocate_kernel_region_with_vmobject(m_shared_framebuffer_vmobject->fake_writes_framebuffer_vmobject(), rounded_size, "Fake Writes Framebuffer"sv, Memory::Region::Access::ReadWrite));
return {};
}
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
ErrorOr<void> DisplayConnector::after_inserting()
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 06:44:46 -03:00
{
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
ArmedScopeGuard clean_from_device_management([&] {
before_will_be_destroyed_remove_from_device_management();
});
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 02:08:53 -03:00
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);
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
ArmedScopeGuard clean_from_sysfs_display_connector_device_directory([&] {
SysFSDisplayConnectorsDirectory::the().unplug({}, *m_sysfs_device_directory);
m_sysfs_device_directory.clear();
});
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 02:08:53 -03:00
VERIFY(!m_symlink_sysfs_component);
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
auto sys_fs_component = TRY(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 02: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 04:39:57 -03:00
after_inserting_add_symlink_to_device_identifier_directory();
Kernel: Get rid of *LockRefPtr in the SysFS filesystem code To do this we also need to get rid of LockRefPtrs in the USB code as well. Most of the SysFS nodes are statically generated during boot and are not mutated afterwards. The same goes for general device code - once we generate the appropriate SysFS nodes, we almost never mutate the node pointers afterwards, making locking unnecessary.
2023-04-05 07:21:11 -03:00
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
ArmedScopeGuard clean_symlink_to_device_identifier_directory([&] {
VERIFY(m_symlink_sysfs_component);
before_will_be_destroyed_remove_symlink_from_device_identifier_directory();
m_symlink_sysfs_component.clear();
});
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 02:08:53 -03:00
Kernel/Graphics: Allocate 16 MiB framebuffer if failed allocating larger We try our best to ensure a DisplayConnector initialization succeeds, and this makes the Intel driver to work again, because if we can't allocate a Region for the whole PCI BAR mapped region, then we will try to allocate a Region with 16 MiB window size, so it doesn't eat the entire Kernel-allocated virtual memory space.
2022-12-22 06:35:35 -03:00
if (auto result_or_error = Memory::page_round_up(m_framebuffer_resource_size); result_or_error.is_error()) {
// NOTE: The amount of framebuffer resource being specified is erroneous, then default to 16 MiB.
TRY(allocate_framebuffer_resources(16 * MiB));
m_framebuffer_resource_size = 16 * MiB;
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-12 21:23:13 -03:00
} else {
Kernel/Graphics: Allocate 16 MiB framebuffer if failed allocating larger We try our best to ensure a DisplayConnector initialization succeeds, and this makes the Intel driver to work again, because if we can't allocate a Region for the whole PCI BAR mapped region, then we will try to allocate a Region with 16 MiB window size, so it doesn't eat the entire Kernel-allocated virtual memory space.
2022-12-22 06:35:35 -03:00
if (auto allocation_result = allocate_framebuffer_resources(result_or_error.release_value()); allocation_result.is_error()) {
// NOTE: The amount of framebuffer resource being specified is too big, use 16 MiB just to get going.
TRY(allocate_framebuffer_resources(16 * MiB));
m_framebuffer_resource_size = 16 * MiB;
}
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-12 21:23:13 -03:00
}
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
clean_from_device_management.disarm();
clean_from_sysfs_display_connector_device_directory.disarm();
clean_symlink_to_device_identifier_directory.disarm();
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-12 21: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 06: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-12 21:23:13 -03:00
if (m_enable_write_combine_optimization) {
[[maybe_unused]] auto result = m_framebuffer_region->set_write_combine(true);
}
Kernel: Get rid of *LockRefPtr in the SysFS filesystem code To do this we also need to get rid of LockRefPtrs in the USB code as well. Most of the SysFS nodes are statically generated during boot and are not mutated afterwards. The same goes for general device code - once we generate the appropriate SysFS nodes, we almost never mutate the node pointers afterwards, making locking unnecessary.
2023-04-05 07:21:11 -03:00
after_inserting_add_to_device_management();
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 17:33:56 -03:00
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 06: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-12 21: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 08: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-12 21: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 06: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-12 21: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 06: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-12 21: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 06: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-12 21: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 06:44:46 -03:00
}
Kernel/Graphics: Ensure VMWare and VirtualBox EDIDs have manufacturer ID
2022-06-10 16: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 06:44:46 -03:00
{
Kernel/Graphics: Ensure VMWare and VirtualBox EDIDs have manufacturer ID
2022-06-10 16: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 06: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 16: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 06: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 16: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 06:44:46 -03:00
set_edid_bytes(virtual_monitor_edid);
return {};
}
Kernel/Graphics: Introduce the IntelDisplayConnectorGroup class In the real world, graphics hardware tend to have multiple display connectors. However, usually the connectors share one register space but still keeping different PLL timings and display lanes. This new class should represent a group of multiple display connectors working together in the same Intel graphics adapter. This opens an opportunity to abstract the interface so we could support future Intel iGPU generations. This is also a preparation before the driver can support newer devices and utilize their capabilities. The mentioned preparation is applied in a these aspects: 1. The code is splitted into more classes to adjust to future expansion. 2 classes are introduced: IntelDisplayPlane and IntelDisplayTranscoder, so the IntelDisplayPlane controls the plane registers and second class controls the pipeline (transcoder, encoder) registers. On gen4 it's not really useful because there are probably one plane and one encoder to care about, but in future generations, there are likely to be multiple transcoders and planes to accommodate multi head support. 2. The set_edid_bytes method in the DisplayConnector class can now be told to not assume the provided EDID bytes are always invalid. Therefore it can refrain from printing error messages if this flag parameter is true. This is useful for supporting real hardware situation when on boot not all ports are connected to a monitor, which can result in floating bus condition (essentially all the bytes we read are 0xFF). 3. An IntelNativeDisplayConnector could now be set to flag other types of connections such as eDP (embedded DisplayPort), Analog output, etc. This is important because on the Intel gen4 graphics we could assume to have one analog output connector, but on future generations this is very likely to not be the case, as there might be no VGA outputs, but rather only an eDP connector which is converted to VGA by a design choice of the motherboard manufacturer. 4. Add ConnectorIndex to IntelNativeDisplayConnector class - Currently this is used to verify we always handle the correct connector when doing modesetting. Later, it will be used to locate special settings needed when handling connector requests. 5. Prepare to support more types of display planes. For example, the Intel Skylake register set for display planes is a bit different, so let's ensure we can properly support it in the near future.
2022-05-05 07:25:51 -03:00
void DisplayConnector::set_edid_bytes(Array<u8, 128> const& edid_bytes, bool might_be_invalid)
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 06:44:46 -03:00
{
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 {
Kernel/Graphics: Introduce the IntelDisplayConnectorGroup class In the real world, graphics hardware tend to have multiple display connectors. However, usually the connectors share one register space but still keeping different PLL timings and display lanes. This new class should represent a group of multiple display connectors working together in the same Intel graphics adapter. This opens an opportunity to abstract the interface so we could support future Intel iGPU generations. This is also a preparation before the driver can support newer devices and utilize their capabilities. The mentioned preparation is applied in a these aspects: 1. The code is splitted into more classes to adjust to future expansion. 2 classes are introduced: IntelDisplayPlane and IntelDisplayTranscoder, so the IntelDisplayPlane controls the plane registers and second class controls the pipeline (transcoder, encoder) registers. On gen4 it's not really useful because there are probably one plane and one encoder to care about, but in future generations, there are likely to be multiple transcoders and planes to accommodate multi head support. 2. The set_edid_bytes method in the DisplayConnector class can now be told to not assume the provided EDID bytes are always invalid. Therefore it can refrain from printing error messages if this flag parameter is true. This is useful for supporting real hardware situation when on boot not all ports are connected to a monitor, which can result in floating bus condition (essentially all the bytes we read are 0xFF). 3. An IntelNativeDisplayConnector could now be set to flag other types of connections such as eDP (embedded DisplayPort), Analog output, etc. This is important because on the Intel gen4 graphics we could assume to have one analog output connector, but on future generations this is very likely to not be the case, as there might be no VGA outputs, but rather only an eDP connector which is converted to VGA by a design choice of the motherboard manufacturer. 4. Add ConnectorIndex to IntelNativeDisplayConnector class - Currently this is used to verify we always handle the correct connector when doing modesetting. Later, it will be used to locate special settings needed when handling connector requests. 5. Prepare to support more types of display planes. For example, the Intel Skylake register set for display planes is a bit different, so let's ensure we can properly support it in the near future.
2022-05-05 07:25:51 -03:00
if (!might_be_invalid) {
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());
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 06:44:46 -03:00
}
}
}
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)
Kernel/Graphics: Return ENODEV if there's no valid EDID to return ENODEV better represents the fact that there might be no display device (e.g. a monitor) connected to the connector, therefore we should return this error. Another reason to not use ENOTIMPL is that it's a requirement for all DisplayConnectors to put a valid EDID in place even for a hardware we don't currently support mode-setting in runtime.
2022-06-03 21:05:36 -03:00
return Error::from_errno(ENODEV);
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 06:44:46 -03:00
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 08: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;
}
Kernel/Graphics: Handle correctly unknown ioctls on a DisplayConnector In such case, we should not assert but instead just return EINVAL.
2022-10-23 08:02:57 -03:00
return "unknown"sv;
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 08:16:28 -03:00
}
Kernel/Graphics: Handle correctly unknown ioctls on a DisplayConnector In such case, we should not assert but instead just return EINVAL.
2022-10-23 08:02:57 -03:00
ErrorOr<bool> DisplayConnector::ioctl_requires_ownership(unsigned request) const
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 08:16:28 -03:00
{
for (auto& checker : s_checkers) {
if (checker.ioctl_number == request)
return checker.requires_ownership;
}
Kernel/Graphics: Handle correctly unknown ioctls on a DisplayConnector In such case, we should not assert but instead just return EINVAL.
2022-10-23 08:02:57 -03:00
// Note: In case of unknown ioctl, return EINVAL.
return Error::from_errno(EINVAL);
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 08:16:28 -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 06: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 02: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 06: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 08: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.
Kernel/Graphics: Handle correctly unknown ioctls on a DisplayConnector In such case, we should not assert but instead just return EINVAL.
2022-10-23 08:02:57 -03:00
auto needs_ownership = TRY(ioctl_requires_ownership(request));
if (needs_ownership) {
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 08:16:28 -03:00
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 06: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 08: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.
Everywhere: Clean up "the the" comment typos
2022-11-03 14:27:18 -03:00
// We could technically return 0 if the requesting process was already
// set to be responsible for this DisplayConnector, but it services
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 08:16:28 -03:00
// 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 08: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 10:55:46 -03:00
VERIFY(m_shared_framebuffer_vmobject);
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 08: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 06: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 10: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 06:44:46 -03:00
return copy_to_user(user_properties, &properties);
}
Everywhere: Rename FB prefix name ioctls => GRAPHICS
2022-04-30 08:49:51 -03:00
case GRAPHICS_IOCTL_GET_HEAD_MODE_SETTING: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 08: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 06: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 08:49:51 -03:00
case GRAPHICS_IOCTL_SET_HEAD_MODE_SETTING: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 08: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 06: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 08: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 06: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 08: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 06: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 08: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 06: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 08:49:51 -03:00
case GRAPHICS_IOCTL_GET_HEAD_VERTICAL_OFFSET_BUFFER: {
Everywhere: Rename FB prefix structure names => Graphics
2022-04-30 08: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 06: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 08:49:51 -03:00
case GRAPHICS_IOCTL_FLUSH_HEAD_BUFFERS: {
Kernel/Graphics: Implement basic support for VMWare SVGA adapter
2022-03-18 11:46:55 -03: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 06: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 07: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 06:44:46 -03:00
return {};
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 07: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 06: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 08: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 06: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 07: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 06:44:46 -03:00
return {};
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 07: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 06:44:46 -03:00
if (!flush_support())
return Error::from_errno(ENOTSUP);
Kernel/Graphics: Apply DisplayConnector design on the VirtIO driver
2022-04-30 07: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 06:44:46 -03:00
TRY(flush_first_surface());
return {};
}
}
Kernel/Graphics: Handle correctly unknown ioctls on a DisplayConnector In such case, we should not assert but instead just return EINVAL.
2022-10-23 08:02:57 -03:00
// Note: We already verify that the IOCTL is supported and not unknown in
// the call to the ioctl_requires_ownership method, so if we reached this
// section of the code, this is bug.
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 06:44:46 -03:00
}
}
Reference in a new issue Copy permalink