259999c9c3
Fix fbcond panicking when vim quit
2025-08-30 12:27:35 +00:00
a6a6dce185
graphics/fbcond: Handle display resizing
...
Currently resizing only happens when writing to the terminal.
2025-07-07 21:59:08 +02:00
b5caa86906
graphics/fbcond: Use the v2 graphics api
2025-07-07 21:59:07 +02:00
93e95f6fe8
graphics: Fix memory leak when resizing the display
2025-07-06 16:22:53 +02:00
ded7a6ed86
graphics/graphics-ipc: Update handle doc comments
2025-07-06 15:30:05 +02:00
918efd01cd
graphics/fbcond: Inline open_display
2025-07-06 15:28:42 +02:00
9abeafde8d
graphics: Move disable-graphical-debug to driver-graphics
...
This ensures it graphical debug gets disabled even when vesad never
runs.
2025-07-05 15:43:21 +02:00
e59d4ac7e1
graphics/vesad: Move FrameBuffer to scheme.rs
2025-07-05 15:21:40 +02:00
04ae0158c9
Update most crates to redox-scheme 0.6
...
A couple of crates need to stay on redox-scheme 0.4 as they need
cancellation for async schemes.
2025-07-04 22:13:24 +02:00
a261f1257d
graphics/virtio-gpud: Destroy virtio-gpu resource before freeing fb memory
...
This fixes a gpu side use-after-free.
2025-07-03 20:57:55 +02:00
cc0db37209
graphics/fbbootlogd: Use the new graphics api
2025-07-02 15:43:55 +02:00
4f7b0eb6b6
graphics: Introduce a new graphics api
...
This allows page flipping and handling display resizing. Hardware
cursors and getting notifications about display resizing are not yet
supported.
2025-07-02 15:43:55 +02:00
27ca1c3296
graphics/virtio-gpud: Handle VIRTIO_GPU_EVENT_DISPLAY
...
This doesn't yet provide a way for individual consumers to resize their
own framebuffer in response to the display changing size.
2025-07-02 15:16:52 +02:00
8ac07539b0
graphics/driver-graphics: Handle mmap offset
2025-07-01 21:46:20 +02:00
565add84b1
graphics/driver-graphics: Update to redox-scheme 0.6
2025-07-01 21:40:57 +02:00
7f3f181775
graphics/virtio-gpud: Create DisplayHandle after registering the scheme
...
This fixes a race-condition. It is unlikely to cause issues in practice
though.
2025-06-30 23:03:40 +02:00
7f5c58892c
graphics/driver-graphics: Eagerly create contents of VtState
2025-06-30 23:01:52 +02:00
7882372dab
graphics/driver-graphics: Introduce VtState
...
This contains the current state for a single VT.
2025-06-30 22:10:02 +02:00
c2249f2fa0
graphics/driver-graphics: Couple of minor changes
2025-06-30 21:40:02 +02:00
993b23e63c
graphics/driver-graphics: Prepare for future abi versions
2025-06-30 20:04:40 +02:00
74bb9f40e5
graphics/graphics-ipc: Introduce a common module for code shared between versions
2025-06-30 19:59:52 +02:00
56d4fdd025
graphics: Replace adapter.displays() with .display_count()
2025-06-30 19:58:25 +02:00
5ddddd91df
graphics: Pass CursorPlane by shared ref to handle_cursor
2025-06-29 18:03:01 +02:00
657bf13d7c
Use library call for iopl.
2025-04-13 21:22:45 +02:00
d318679112
graphics/fbbootlogd: Tell logd to use us as log sink
2025-04-06 20:11:47 +02:00
65c23ed77d
graphics/vesad: Disable kernel graphical debug as late as possible
2025-04-06 17:12:10 +02:00
f1b5ba52ed
Rustfmt
2025-04-04 20:41:31 +02:00
215b8185c2
Handle vt switching for cursors without requiring a cursor update
...
This requires storing the cursor state on the driver-graphics side to be
be able to restore the correct state for the target vt.
2025-04-04 20:37:43 +02:00
abab5c9a3c
Avoid passing unused fields to VIRTIO_GPU_CMD_MOVE_CURSOR
2025-04-04 20:25:57 +02:00
03cf0955d2
Move cursor resource writing to driver-graphics
2025-04-04 20:04:25 +02:00
de4cc6ed4a
adding support for gpu cursor
2025-04-03 21:21:32 +00:00
bbac3ff4f4
Merge branch 'fix_damage' into 'master'
...
graphics/console-draw: Fix damage calculation
See merge request redox-os/drivers!259
2025-03-15 21:42:00 +00:00
7e6534ff35
graphics/console-draw: Fix damage calculation
2025-03-15 22:09:14 +01:00
fb24979c51
Reduce verbosity of debug logs during booting
...
These logs are only useful when actively working on the respective driver.
2025-03-15 21:09:12 +01:00
f48ae933ff
graphics: Only allow passing a single damage area at a time
...
Currently only fbbootlogd and fbcond make use of support for multiple
damage areas and they are not all that performance critical anyway.
Orbital always passes a single damage area per write call. Out of all
graphics drivers we have and are likely to get only vesad could
potentially benefit from fine-grained damage areas. This commit doesn't
significantly impact performance of fbcond.
2025-03-15 18:49:59 +01:00
ffbfecbdb0
graphics/fbcond: Make it robust against initial graphics driver being broken
2025-03-15 17:30:39 +01:00
87d71bc708
graphics/fbbootlogd: Merge Display into FbbbootlogScheme
2025-03-15 17:27:14 +01:00
54113f8fde
graphics/fbbootlogd: Make it robust against initial graphics driver being broken
2025-03-15 17:21:23 +01:00
9290cffa70
graphics/fbbootlogd: Extract handle_handoff method
2025-03-15 17:18:28 +01:00
b9d043f6e2
inputd: Add ConsumerHandle::read_events
2025-03-15 17:09:45 +01:00
56808dbfb1
graphics/fbbootlogd: Remove input events background thread
2025-03-15 16:53:58 +01:00
943cbe3707
graphics/fbbootlogd: Remove workaround that prevents blocking on the graphics driver
...
Instead logd will no longer block on fbbootlogd to prevent the deadlock
that this worked around.
2025-03-15 16:53:44 +01:00
5d76acfd74
Update to redox-scheme 0.4
2025-03-14 22:11:30 +01:00
7bb1693e86
graphics/graphics-ipc: Fix Damage::clip
2025-03-13 19:04:28 +01:00
f2d3d16455
graphics/bgad: Use redox-scheme
2025-03-13 17:00:54 +01:00
09ef96ae80
graphics/drivers-graphics: Fix some comments and remove no longer necessary feature
2025-03-13 17:00:54 +01:00
be5b865058
graphics: Rename resource to framebuffer
...
This matches the Linux DRM name.
2025-03-06 21:41:26 +01:00
92295f2ea4
graphics/graphics-ipc: Use u32 fields in Damage
...
The fields should never be negative and this saves a couple of casts.
2025-03-06 20:49:21 +01:00
ee3382aed0
graphics/virtio-gpud: Add helper to submit a fenced request
...
This is necessary for implementing hardware cursor support.
2025-03-06 20:49:20 +01:00
fc92f0b0ce
graphics: Rename the legacy graphics API to the v1 graphics API
...
It is quite likely that the next graphics API won't be the last one and
as such would become a legacy API too. Consistently using version
numbers makes it easier to refer to the exact version you mean.
2025-03-06 20:49:20 +01:00
Wildan Mubarok