plymouth merge requestshttps://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests2024-03-22T22:19:23Zhttps://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/313drm: Use drmModeCloseFB for flicker-free login2024-03-22T22:19:23ZJocelyn Falempedrm: Use drmModeCloseFB for flicker-free loginUse CloseFB ioctl if available, as it allows to keep the last frame
from plymouth displayed until the login manager take control.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>Use CloseFB ioctl if available, as it allows to keep the last frame
from plymouth displayed until the login manager take control.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/238client/server: allow longer status string2023-12-25T18:15:40ZSven Brinkmannclient/server: allow longer status stringUse 2 instead of 1 byte for the status length when sending status
udptaes to the demon.
Also make sure to assert less than when checking the argument size.
fixes #212Use 2 instead of 1 byte for the status length when sending status
udptaes to the demon.
Also make sure to assert less than when checking the argument size.
fixes #212https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/173Draft: drm: use CLOSEFB when available2024-03-22T22:19:23ZSimon Sercontact@emersion.frDraft: drm: use CLOSEFB when availableThis leaves our last FB on screen, and allows the next DRM master
to perform a flicker-free transition.
See:
- Kernel patch: https://lore.kernel.org/dri-devel/20211007131507.149734-1-contact@emersion.fr/T/
- https://gitlab.freedesktop....This leaves our last FB on screen, and allows the next DRM master
to perform a flicker-free transition.
See:
- Kernel patch: https://lore.kernel.org/dri-devel/20211007131507.149734-1-contact@emersion.fr/T/
- https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/141#note_1259488https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/161Draft: Add support for HiDPI images and animations2022-04-17T04:12:37ZHans Christian SchmitzDraft: Add support for HiDPI images and animationsCurrently I have modified `ply-image` to support loading an image assuming a scale, or to have it try loading an alternative at a given device scale. Opaquely making `ply-image` load the image data at a device scale doesn't really work t...Currently I have modified `ply-image` to support loading an image assuming a scale, or to have it try loading an alternative at a given device scale. Opaquely making `ply-image` load the image data at a device scale doesn't really work to my knowledge, since `ply-image` is used both per-view and per-plugin, and in the latter case there can be multiple-different device scales required.
There's also a `ply-multiscale-image` now, for images that are available in multiple resolutions, which takes care of loading these different resolutions and picking the right one for a given scale (to replace the use of plugin level images, which are used across different views with possibly different device scales).
Since icons are already per-view I've just made them accept a device scale and use that for loading their image (falling back to scale 1 if no version at the device scale is available).
`ply-animation` is also used per-view only, so I'm currently working on just having it load either versions of the images at the correct scale or if not available (even in part, i.e. if the number of images at a given scale differ) fall back to the default scale of 1.
The naming scheme I'm currently using just has the current names for scale 1 (e.g. `keyboard.png`) and names suffixed with `@<scale>` (e.g. `keyboard@2.png`) for a given device scale.
Current remaining TODOs:
* [x] ~Figuring out why I'm only getting device scales of 1 in my plymouth tests with the X11/GTK backend on my 4k displays.~
* [ ] Getting HiDPI animations to work properly
* [ ] HiDPI support for `ply-entry`
* [x] HiDPI support for `ply-throbber`
* [ ] HiDPI support for other custom animations (probably using newly introduced `ply-image-sequence`)
So far I'm just assuming that device scales are either 2 or 1, but I do try to write my code in a way that it could deal with alternative scales as well.
The current code still has some issues and might need some re-organizing (hence a draft PR for now), but I'm slowly getting somewhere.
Fixes #76.https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/154ply-rectangle: Use floats for storing position2022-07-29T17:50:27ZSebastian Krzyszkowiakply-rectangle: Use floats for storing positionOn high DPI screens, ply_rectangles get transformed between logical and
device coordinate system a lot. However, going from device to logical
coords is a lossy operation when using integers to store the position.
An example of why this ...On high DPI screens, ply_rectangles get transformed between logical and
device coordinate system a lot. However, going from device to logical
coords is a lossy operation when using integers to store the position.
An example of why this is problematic can be seen in
ply_pixel_buffer_fill_with_argb32_data_at_opacity_with_clip_and_scale,
where fill_area passed in device coords is scaled down to logical coords
and then used to determine cropped_area expressed back in device coords.
When fill_area has a position that isn't divisible by scale factor, this
ends up with out-of-bounds reads since cropped_area ends up with position
values smaller than fill_area's due to integer rounding.
This is solved by changing the type of ply_rectangle's position to float,
which makes coordinate transformations properly lossless.