7
submitted 1 month ago by Atemu@lemmy.ml to c/bicycles@lemmy.ca

So I let the chain wear down too much in the past two years and the rear sprockets appear to be worn out and will need to be replaced. The stock 50T chain ring is also showing signs of wear but appears to still be good for a few years.

I wanted to use this opportunity to see whether I could switch the gearing up a little.

The 13-16 gearing has been surprisingly capable but I need just a little more hill climbing ability; the lowest gear (2.64m) is just barely enough sometimes. I'd like it a tad lower I think.

On the high end, I usually ride in the upper two gears on flat ground. The highest gear (7.98m) feels just a tad too much sometimes though and I then fall back to one lower (6.49m) but that feels a good bit too low. That doesn't bother me a lot but it'd still be nicer to have a gear that's just right.

On a downhill, the highest gear is always sufficient for me; feels pretty much exactly right. I wouldn't mind slightly more metres of development but, honestly, I don't care very much when I'm already going way past 30km/h and I don't ride downhill for very long usually. I'm unsure whether reducing the highest gear slightly would make me pedal uncomfortably quickly down hill though.

Stock and current config:

Hub 64% 100% 157%
Low sprocket 2.64 4.14 6.49
High sprocket 3.25 5.10 7.98

I'm currently thinking about a 44T chain ring with 12-17:

Hub 64% 100% 157%
Low sprocket 2.19 3.43 5.37
High sprocket 3.10 4.86 7.61

or 12-16:

Hub 64% 100% 157%
Low sprocket 2.33 3.64 5.71
High sprocket 3.10 4.86 7.61

The lower gears being lower and closer together sounds very nice.

In the higher gears, my hope is that the slightly lower highest gear would allow me to use it the majority of the time on flat ground because I suspect the second highest gear would feel quite a bit too low as a fall-back.

I could see 12-15 being an option perhaps but that also gets the lowest gear much closer to 13-16 again:

Hub 64% 100% 157%
Low sprocket 2.48 3.89 6.09
High sprocket 3.10 4.86 7.61

But obviously the lowest gear gets very close to the previous config again.

Where I have a hard time is imagining how significant the difference between 2.64m, 2.19m, 2.33m and 2.48m are in an uphill scenario. The jump between the lower gears in 13-16 (3.25m to 2.64m) in practice feels significant but not that large either and we're talking about a much lower absolute drop being gained in the low end by switching gearing. I don't know whether the practical effect of this is linear though and I suspect it might not be.

I'd really appreciate practical experience here. Have you changed gearing on your Brompton? From what to what and how significant were the differences?

[-] Atemu@lemmy.ml 60 points 1 month ago

If you wanted a distro where everything is set up for you OOTB, not requiring tinkering, you should not have installed Arch mate.

6
submitted 2 months ago by Atemu@lemmy.ml to c/linux@lemmy.world
48
submitted 2 months ago by Atemu@lemmy.ml to c/android@lemmy.ml

scrcpy v3.0

Changes since v2.7:

  • Add virtual display feature (#5370, #5506, #1887, #4528, #5137)
  • Launch Android app on start (#5370)
  • Add OpenGL filters (#5455)
  • Add --capture-orientation to replace --lock-video-orientation (which was broken on Android 14) (#4011, #4426, #5455)
  • Fix --crop on Android 14 (#4162, #5387, #5455)
  • Handle virtual display rotation (#5428, #5455)
  • Add --angle to apply a custom rotation (#4135, #4345, #4658, #5455)
  • Add --screen-off-timeout (#5447)
  • Adapt "turn screen off" for Android 15 (#3927, #5418)
  • Add shortcut Ctrl+Shift+click-and-move for horizontal tilt (#5317)
  • Add shortcut MOD+Shift+r to reset video capture/encoding (#5432)
  • Forward Alt and Super with SDK Keyboard (#5318, #5322)
  • Add more details to --list-encoders output (#5416)
  • Add option to disable virtual display system decorations (#5494)
  • Fix --time-limit overflow on Windows (#5355)
  • Fix "does not match caller's uid 2000" error (#4639, #5476)
  • Accept filenames containing ':' when recording (#5487, #5499)
  • Disable mouse by default if no video playback (#5410)
  • Rename --display-buffer to --video-buffer (#5403, #5420)
  • Listen to display changed events (#5415, #161, #1918, #4152, #5362)
  • Adapt server debugging for Android >= 11 (#5346, #5466)
  • Upgrade FFmpeg to 7.1 (#5332)
  • Upgrade SDL to 2.30.9
  • Upgrade platform-tools (adb) to 35.0.2
  • Build releases via GitHub Actions (#5306, #4490)
  • Release static builds for Linux and macOS (#5515, #1733, #3235, #4489, #5327)
  • Various technical fixes

Highlights

Virtual display

By default, scrcpy mirrors the device screen.

With this new feature (#5370), it is now possible to mirror a new virtual display, with a custom size:

scrcpy --new-display=1920x1080
scrcpy --new-display=1920x1080/420  # force 420 dpi
scrcpy --new-display         # use the main display size and density
scrcpy --new-display=/240    # use the main display size and 240 dpi

On some devices, a launcher is available in the virtual display.

When no launcher is available, the virtual display is empty. In that case, you must start an Android app.

For example:

scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc

To list the Android apps installed on the device:

scrcpy --list-apps

For convenience, you can also select an app by its name using a ? prefix:

scrcpy --start-app=?firefox

However, retrieving app names may take some time (sometimes several seconds), so passing the package name is recommended.

On-device OpenGL filters

Scrcpy can now transform the captured video stream before encoding by applying OpenGL filters directly on the device. This has made it possible to fix several issues and implement new features, as described below (more details in #5455).

Crop

The --crop option was broken for devices running Android >= 14 (#4162). It has been reimplemented using OpenGL filters internally.

Its usage remains the same:

scrcpy --crop=800:600:100:100

It now also works for camera and virtual displays.

Capture orientation

The --lock-video-orientation option was broken for devices running Android >= 14 (#4011).

It has been replaced by a more general option --capture-orientation, implemented using OpenGL filters:

scrcpy --capture-orientation=0
scrcpy --capture-orientation=90       # 90° clockwise
scrcpy --capture-orientation=180      # 180°
scrcpy --capture-orientation=270      # 270° clockwise
scrcpy --capture-orientation=flip0    # hflip
scrcpy --capture-orientation=flip90   # hflip + 90° clockwise
scrcpy --capture-orientation=flip180  # hflip + 180°
scrcpy --capture-orientation=flip270  # hflip + 270° clockwise

The capture orientation can be locked by using a @ prefix, so that a physical device rotation does not change the captured video orientation:

scrcpy --capture-orientation=@         # locked to the initial orientation
scrcpy --capture-orientation=@0        # locked to 0°
scrcpy --capture-orientation=@90       # locked to 90° clockwise
scrcpy --capture-orientation=@180      # locked to 180°
scrcpy --capture-orientation=@270      # locked to 270° clockwise
scrcpy --capture-orientation=@flip0    # locked to hflip
scrcpy --capture-orientation=@flip90   # locked to hflip + 90° clockwise
scrcpy --capture-orientation=@flip180  # locked to hflip + 180°
scrcpy --capture-orientation=@flip270  # locked to hflip + 270° clockwise

Now, it also works for camera (fixing #4426) and virtual displays.

Custom rotation

A new option --angle allows to rotate the content by a custom angle. Combined with --crop, this is especially useful for mirroring the Meta Quest 3 (#4135, #4345, #4658).

Virtual display rotation

The new virtual display feature initially could not rotate. The rotation has been implemented using OpenGL filters.

(That is what triggered the development of OpenGL filters.)

Like previously, the current app can be rotated by MOD+r (shortcuts).

Screen off timeout

The existing option --stay-awake only keeps the device awake *while it is plugged in, meaning it typically does not work over TCP/IP.

A new option, --screen-off-timeout, modifies the screen-off timeout setting while scrcpy is running and restores it on exit:

scrcpy --screen-off-timeout=300  # 300 seconds (5 minutes)

Static builds

For convenience, static builds are now provided for Linux and macOS (#5515).

More targets might be added in the future.

This is still experimental for now, so if you encounter problems, please report them.

Features you might have missed

If you haven't tried scrcpy in a while, here are some features introduced in the 2.x versions that you might have missed (check the release notes to each version for more details):


17
submitted 2 months ago by Atemu@lemmy.ml to c/android@lemdro.id

scrcpy v3.0

Changes since v2.7:

  • Add virtual display feature (#5370, #5506, #1887, #4528, #5137)
  • Launch Android app on start (#5370)
  • Add OpenGL filters (#5455)
  • Add --capture-orientation to replace --lock-video-orientation (which was broken on Android 14) (#4011, #4426, #5455)
  • Fix --crop on Android 14 (#4162, #5387, #5455)
  • Handle virtual display rotation (#5428, #5455)
  • Add --angle to apply a custom rotation (#4135, #4345, #4658, #5455)
  • Add --screen-off-timeout (#5447)
  • Adapt "turn screen off" for Android 15 (#3927, #5418)
  • Add shortcut Ctrl+Shift+click-and-move for horizontal tilt (#5317)
  • Add shortcut MOD+Shift+r to reset video capture/encoding (#5432)
  • Forward Alt and Super with SDK Keyboard (#5318, #5322)
  • Add more details to --list-encoders output (#5416)
  • Add option to disable virtual display system decorations (#5494)
  • Fix --time-limit overflow on Windows (#5355)
  • Fix "does not match caller's uid 2000" error (#4639, #5476)
  • Accept filenames containing ':' when recording (#5487, #5499)
  • Disable mouse by default if no video playback (#5410)
  • Rename --display-buffer to --video-buffer (#5403, #5420)
  • Listen to display changed events (#5415, #161, #1918, #4152, #5362)
  • Adapt server debugging for Android >= 11 (#5346, #5466)
  • Upgrade FFmpeg to 7.1 (#5332)
  • Upgrade SDL to 2.30.9
  • Upgrade platform-tools (adb) to 35.0.2
  • Build releases via GitHub Actions (#5306, #4490)
  • Release static builds for Linux and macOS (#5515, #1733, #3235, #4489, #5327)
  • Various technical fixes

Highlights

Virtual display

By default, scrcpy mirrors the device screen.

With this new feature (#5370), it is now possible to mirror a new virtual display, with a custom size:

scrcpy --new-display=1920x1080
scrcpy --new-display=1920x1080/420  # force 420 dpi
scrcpy --new-display         # use the main display size and density
scrcpy --new-display=/240    # use the main display size and 240 dpi

On some devices, a launcher is available in the virtual display.

When no launcher is available, the virtual display is empty. In that case, you must start an Android app.

For example:

scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc

To list the Android apps installed on the device:

scrcpy --list-apps

For convenience, you can also select an app by its name using a ? prefix:

scrcpy --start-app=?firefox

However, retrieving app names may take some time (sometimes several seconds), so passing the package name is recommended.

On-device OpenGL filters

Scrcpy can now transform the captured video stream before encoding by applying OpenGL filters directly on the device. This has made it possible to fix several issues and implement new features, as described below (more details in #5455).

Crop

The --crop option was broken for devices running Android >= 14 (#4162). It has been reimplemented using OpenGL filters internally.

Its usage remains the same:

scrcpy --crop=800:600:100:100

It now also works for camera and virtual displays.

Capture orientation

The --lock-video-orientation option was broken for devices running Android >= 14 (#4011).

It has been replaced by a more general option --capture-orientation, implemented using OpenGL filters:

scrcpy --capture-orientation=0
scrcpy --capture-orientation=90       # 90° clockwise
scrcpy --capture-orientation=180      # 180°
scrcpy --capture-orientation=270      # 270° clockwise
scrcpy --capture-orientation=flip0    # hflip
scrcpy --capture-orientation=flip90   # hflip + 90° clockwise
scrcpy --capture-orientation=flip180  # hflip + 180°
scrcpy --capture-orientation=flip270  # hflip + 270° clockwise

The capture orientation can be locked by using a @ prefix, so that a physical device rotation does not change the captured video orientation:

scrcpy --capture-orientation=@         # locked to the initial orientation
scrcpy --capture-orientation=@0        # locked to 0°
scrcpy --capture-orientation=@90       # locked to 90° clockwise
scrcpy --capture-orientation=@180      # locked to 180°
scrcpy --capture-orientation=@270      # locked to 270° clockwise
scrcpy --capture-orientation=@flip0    # locked to hflip
scrcpy --capture-orientation=@flip90   # locked to hflip + 90° clockwise
scrcpy --capture-orientation=@flip180  # locked to hflip + 180°
scrcpy --capture-orientation=@flip270  # locked to hflip + 270° clockwise

Now, it also works for camera (fixing #4426) and virtual displays.

Custom rotation

A new option --angle allows to rotate the content by a custom angle. Combined with --crop, this is especially useful for mirroring the Meta Quest 3 (#4135, #4345, #4658).

Virtual display rotation

The new virtual display feature initially could not rotate. The rotation has been implemented using OpenGL filters.

(That is what triggered the development of OpenGL filters.)

Like previously, the current app can be rotated by MOD+r (shortcuts).

Screen off timeout

The existing option --stay-awake only keeps the device awake *while it is plugged in, meaning it typically does not work over TCP/IP.

A new option, --screen-off-timeout, modifies the screen-off timeout setting while scrcpy is running and restores it on exit:

scrcpy --screen-off-timeout=300  # 300 seconds (5 minutes)

Static builds

For convenience, static builds are now provided for Linux and macOS (#5515).

More targets might be added in the future.

This is still experimental for now, so if you encounter problems, please report them.

Features you might have missed

If you haven't tried scrcpy in a while, here are some features introduced in the 2.x versions that you might have missed (check the release notes to each version for more details):


77
submitted 2 months ago by Atemu@lemmy.ml to c/android@lemmy.world

scrcpy v3.0

Changes since v2.7:

  • Add virtual display feature (#5370, #5506, #1887, #4528, #5137)
  • Launch Android app on start (#5370)
  • Add OpenGL filters (#5455)
  • Add --capture-orientation to replace --lock-video-orientation (which was broken on Android 14) (#4011, #4426, #5455)
  • Fix --crop on Android 14 (#4162, #5387, #5455)
  • Handle virtual display rotation (#5428, #5455)
  • Add --angle to apply a custom rotation (#4135, #4345, #4658, #5455)
  • Add --screen-off-timeout (#5447)
  • Adapt "turn screen off" for Android 15 (#3927, #5418)
  • Add shortcut Ctrl+Shift+click-and-move for horizontal tilt (#5317)
  • Add shortcut MOD+Shift+r to reset video capture/encoding (#5432)
  • Forward Alt and Super with SDK Keyboard (#5318, #5322)
  • Add more details to --list-encoders output (#5416)
  • Add option to disable virtual display system decorations (#5494)
  • Fix --time-limit overflow on Windows (#5355)
  • Fix "does not match caller's uid 2000" error (#4639, #5476)
  • Accept filenames containing ':' when recording (#5487, #5499)
  • Disable mouse by default if no video playback (#5410)
  • Rename --display-buffer to --video-buffer (#5403, #5420)
  • Listen to display changed events (#5415, #161, #1918, #4152, #5362)
  • Adapt server debugging for Android >= 11 (#5346, #5466)
  • Upgrade FFmpeg to 7.1 (#5332)
  • Upgrade SDL to 2.30.9
  • Upgrade platform-tools (adb) to 35.0.2
  • Build releases via GitHub Actions (#5306, #4490)
  • Release static builds for Linux and macOS (#5515, #1733, #3235, #4489, #5327)
  • Various technical fixes

Highlights

Virtual display

By default, scrcpy mirrors the device screen.

With this new feature (#5370), it is now possible to mirror a new virtual display, with a custom size:

scrcpy --new-display=1920x1080
scrcpy --new-display=1920x1080/420  # force 420 dpi
scrcpy --new-display         # use the main display size and density
scrcpy --new-display=/240    # use the main display size and 240 dpi

On some devices, a launcher is available in the virtual display.

When no launcher is available, the virtual display is empty. In that case, you must start an Android app.

For example:

scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc

To list the Android apps installed on the device:

scrcpy --list-apps

For convenience, you can also select an app by its name using a ? prefix:

scrcpy --start-app=?firefox

However, retrieving app names may take some time (sometimes several seconds), so passing the package name is recommended.

On-device OpenGL filters

Scrcpy can now transform the captured video stream before encoding by applying OpenGL filters directly on the device. This has made it possible to fix several issues and implement new features, as described below (more details in #5455).

Crop

The --crop option was broken for devices running Android >= 14 (#4162). It has been reimplemented using OpenGL filters internally.

Its usage remains the same:

scrcpy --crop=800:600:100:100

It now also works for camera and virtual displays.

Capture orientation

The --lock-video-orientation option was broken for devices running Android >= 14 (#4011).

It has been replaced by a more general option --capture-orientation, implemented using OpenGL filters:

scrcpy --capture-orientation=0
scrcpy --capture-orientation=90       # 90° clockwise
scrcpy --capture-orientation=180      # 180°
scrcpy --capture-orientation=270      # 270° clockwise
scrcpy --capture-orientation=flip0    # hflip
scrcpy --capture-orientation=flip90   # hflip + 90° clockwise
scrcpy --capture-orientation=flip180  # hflip + 180°
scrcpy --capture-orientation=flip270  # hflip + 270° clockwise

The capture orientation can be locked by using a @ prefix, so that a physical device rotation does not change the captured video orientation:

scrcpy --capture-orientation=@         # locked to the initial orientation
scrcpy --capture-orientation=@0        # locked to 0°
scrcpy --capture-orientation=@90       # locked to 90° clockwise
scrcpy --capture-orientation=@180      # locked to 180°
scrcpy --capture-orientation=@270      # locked to 270° clockwise
scrcpy --capture-orientation=@flip0    # locked to hflip
scrcpy --capture-orientation=@flip90   # locked to hflip + 90° clockwise
scrcpy --capture-orientation=@flip180  # locked to hflip + 180°
scrcpy --capture-orientation=@flip270  # locked to hflip + 270° clockwise

Now, it also works for camera (fixing #4426) and virtual displays.

Custom rotation

A new option --angle allows to rotate the content by a custom angle. Combined with --crop, this is especially useful for mirroring the Meta Quest 3 (#4135, #4345, #4658).

Virtual display rotation

The new virtual display feature initially could not rotate. The rotation has been implemented using OpenGL filters.

(That is what triggered the development of OpenGL filters.)

Like previously, the current app can be rotated by MOD+r (shortcuts).

Screen off timeout

The existing option --stay-awake only keeps the device awake *while it is plugged in, meaning it typically does not work over TCP/IP.

A new option, --screen-off-timeout, modifies the screen-off timeout setting while scrcpy is running and restores it on exit:

scrcpy --screen-off-timeout=300  # 300 seconds (5 minutes)

Static builds

For convenience, static builds are now provided for Linux and macOS (#5515).

More targets might be added in the future.

This is still experimental for now, so if you encounter problems, please report them.

Features you might have missed

If you haven't tried scrcpy in a while, here are some features introduced in the 2.x versions that you might have missed (check the release notes to each version for more details):


6
submitted 2 months ago by Atemu@lemmy.ml to c/linux_gaming@lemmy.world

This is a big release, adding several new major features:

  • Nvidia support! LACT now works with Nvidia GPUs for all of the core functionality (monitoring, clocks configuration, power limits and fan control). It uses the NVML library, so unlike the Nvidia control panel it doesn't rely on X11 extensions and works under Wayland.
  • Multiple profiles for configuration. Currently it is not possible to switch them automatically, but they are configurable through the UI or the unix socket.
  • Clocks configuration now works on AMD IGPUs (at least RDNA2). Previously it was not parsed properly due to lack of VRAM settings.
  • Zero RPM mode settings on RDNA3. Currently this needs a linux-next to be used, and the functionality is expected to land in kernel 6.13. But this resolves a long-standing issue with RDNA3 that made the fan always disabled below a certain temperature, even if using a custom curve.

There are many other improvements as well, such as better looking and more efficient plots rendering in the historical charts window (thanks to @In-line ) and a Fedora COPR repository providing LACT packages (currently in testing).

Nvidia showcase:

image image

Full list of changes:

🚀 Features

  • Add support for multiple settings profiles (#327)
  • Show dialog when attempting to reconnect to daemon
  • Include device info and stats responses in debug snapshot
  • Improve plot rendering, use supersampling and do it in a background thread
  • [breaking] Add initial Nvidia support (#388)
  • Implement clocks control on Nvidia (#398)
  • Add special case for invalid throttle mask
  • Add snapshot command to CLI
  • Add RDNA3 zero RPM setting (#393)

🐛 Bug Fixes

  • Getting pci info in snapshot
  • Retry reading p-states if the value is nonsensical
  • Increase retry intervals when evaluating GPUs at start
  • Make throttling flags ellipsized to avoid massively oversized window (#402)
  • Deduplicate throttle status bits
  • Update amdgpu-sysfs with iGPU fixes, add steam deck quirk (#407)
  • Fedora spec non-default builds (#410)

🚜 Refactor

  • Make info page a relm component (#404)
  • Drop redundant ClockSettings structure in the ui

📚 Documentation

  • Update issue template to mention common RDNA3 problems
  • Fix issue template yaml
  • Move description to label in issue template

⚙️ Miscellaneous Tasks

  • Bump version
  • Update docs, enforce minimum rust version
  • Set codegen-units=1 to decrease binary size in release (#390)
  • Include service log in debug snapshot
  • Drop old bench feature
  • Bump dependencies
  • Bump version
  • Remove unused Cargo features (#405)

Developer

  • Automatically create release on tag push
  • Trigger workflow on tag push
  • Bump workflow rust version
  • Add debug builds to makefile
  • Skip building signed packages if signing secret is not found
  • Don't run rust checks on master pushes, only PRs

Packaging

  • Add libdrm to debian dependencies
  • Add fedora 41 package (#399)
  • Generate Spec Files for COPR on Release Publish (#406)
  • Drop invalid copr trigger check
20
submitted 2 months ago by Atemu@lemmy.ml to c/linux_gaming@lemmy.ml

This is a big release, adding several new major features:

  • Nvidia support! LACT now works with Nvidia GPUs for all of the core functionality (monitoring, clocks configuration, power limits and fan control). It uses the NVML library, so unlike the Nvidia control panel it doesn't rely on X11 extensions and works under Wayland.
  • Multiple profiles for configuration. Currently it is not possible to switch them automatically, but they are configurable through the UI or the unix socket.
  • Clocks configuration now works on AMD IGPUs (at least RDNA2). Previously it was not parsed properly due to lack of VRAM settings.
  • Zero RPM mode settings on RDNA3. Currently this needs a linux-next to be used, and the functionality is expected to land in kernel 6.13. But this resolves a long-standing issue with RDNA3 that made the fan always disabled below a certain temperature, even if using a custom curve.

There are many other improvements as well, such as better looking and more efficient plots rendering in the historical charts window (thanks to @In-line ) and a Fedora COPR repository providing LACT packages (currently in testing).

Nvidia showcase:

image image

Full list of changes:

🚀 Features

  • Add support for multiple settings profiles (#327)
  • Show dialog when attempting to reconnect to daemon
  • Include device info and stats responses in debug snapshot
  • Improve plot rendering, use supersampling and do it in a background thread
  • [breaking] Add initial Nvidia support (#388)
  • Implement clocks control on Nvidia (#398)
  • Add special case for invalid throttle mask
  • Add snapshot command to CLI
  • Add RDNA3 zero RPM setting (#393)

🐛 Bug Fixes

  • Getting pci info in snapshot
  • Retry reading p-states if the value is nonsensical
  • Increase retry intervals when evaluating GPUs at start
  • Make throttling flags ellipsized to avoid massively oversized window (#402)
  • Deduplicate throttle status bits
  • Update amdgpu-sysfs with iGPU fixes, add steam deck quirk (#407)
  • Fedora spec non-default builds (#410)

🚜 Refactor

  • Make info page a relm component (#404)
  • Drop redundant ClockSettings structure in the ui

📚 Documentation

  • Update issue template to mention common RDNA3 problems
  • Fix issue template yaml
  • Move description to label in issue template

⚙️ Miscellaneous Tasks

  • Bump version
  • Update docs, enforce minimum rust version
  • Set codegen-units=1 to decrease binary size in release (#390)
  • Include service log in debug snapshot
  • Drop old bench feature
  • Bump dependencies
  • Bump version
  • Remove unused Cargo features (#405)

Developer

  • Automatically create release on tag push
  • Trigger workflow on tag push
  • Bump workflow rust version
  • Add debug builds to makefile
  • Skip building signed packages if signing secret is not found
  • Don't run rust checks on master pushes, only PRs

Packaging

  • Add libdrm to debian dependencies
  • Add fedora 41 package (#399)
  • Generate Spec Files for COPR on Release Publish (#406)
  • Drop invalid copr trigger check
37
DXVK Version 2.5 (github.com)
submitted 3 months ago by Atemu@lemmy.ml to c/linux_gaming@lemmy.ml

Memory managment

Resource and memory management were completely rewritten in order to use allocated video memory more efficiently:

  • Reduced fragmentation may reduce peak memory usage in games such as God of War by up to 1 GiB in extreme cases.
  • Memory defragmentation is now performed periodically to return some unused memory back to the system. The goal is not to reduce VRAM usage at all costs; instead this is done conservatively if the system is under memory pressure, or if a significant amount of allocated memory is unused. Keeping some unused memory is useful to quickly service subsequent allocations.

Note: Defragmentation is currently disabled on Intel's ANV driver, see #4434. The dxvk.enableMemoryDefrag config option can be set to enable or disable this feature via the the Configuration file.

Driver support

While technically not required, the new memory management works best on drivers that support both VK_EXT_memory_budget and VK_KHR_maintenance5. The Driver Support page was updated accordingly.

D3D8 / D3D9

Software cursor

Support for emulated cursors was implemented for the D3D9 cursor API, which allows games to set an arbitrary image as the mouse cursor. This fixes an issue in Dungeon Siege 2 (#3020) and makes the cursor appear correctly in Act of War and various older D3D8 games. (PR #4302)

Bildschirmfoto-693

Sampler pool

Unreal Engine 3 games using D3D9 have a quirk in that they pass a seemingly uninitialized value as the mipmap LOD bias. In order to avoid creating more Vulkan sampler objects than the driver supports, previous versions of DXVK would round the LOD bias to a multiple of 0.5, which could introduce visual inaccuracies. As a more correct soluition, DXVK will now destroy unused Vulkan samplers on the fly and use the correct LOD bias.

Note: The aforementioned workaround was never needed or used in the D3D11 implementation, it only affected D3D9.

Bug fixes and Improvements

  • On Nvidia driver version 565.57.01 and newer, strict float emulation is enabled by default for improved correctness. Games for which this option was already enabled may see a small performance uplift on this driver.
  • Made various changes to potentially improve performace on certain mobile GPUs. (includes PR #4358)
  • Display modes are now ordered by refresh rate to be more consistent with wined3d and fix issues with some games picking the wrong display mode.
  • Fixed a large number of wine test failures.
  • Ascension to the Throne: Fixed old regression that would cause parts of the ground to render black. (#4338, PR #4341)
  • Command & Conquer: Generals: Fixed performance issue caused by a missing D3D8 entry point. (PR #4342)
  • King's Bounty: Warriors of the North: Fixed water rendering issue. (#4344, PR #4350)
  • Tomb Raider: Legend: Fixed flickering geometry with strict float emulation. (#4319, PR #4442)
  • Rayman 3: Fixed a regression that caused rendering issues. (#4422, PR #4423)

D3D11 / DXGI

Resource management changes

In order to reduce system memory pressure and improve stability in 32-bit games, creating, uploading and discarding resources is now throttled if the amount of temporary staging memory allocations exceed a certain threshold. This fixes crashes in Total War: Rome II and a number of other games. Additionally, large DYNAMIC textures commonly used for video playback will no longer use a staging buffer.

The d3d11.maxDynamicImageBufferSize and d3d11.maxImplicitDiscardSize options were removed accordingly; affected games such as Total War: Warhammer III and Ryse: Son of Rome should now perform well by default, without excessive memory usage.

Note: These changes negatively affect CPU-bound performance in a number of games, including Shadow Warrior 2.

Bug fixes and Improvements

  • SEQUENTIAL swap effects are now implemented for DXGI swap chains, which allows games to read previously presented backbuffers. This fixes an issue wherein savegame thumbnails would appear black in certain visual novels. (https://github.com/ValveSoftware/Proton/issues/7017)
  • Devirtualized some D3D11 method calls to improve compatibility with Special K.
  • Fixed incorrect shader code generation for EvaluateAttributeSnapped.
  • Lock contention is reduced in certain games that use Deferred Contexts for rendering. This may improve performance on older CPUs in Sekiro: Shadows Die Twice and some other games.
  • Call of Duty: Modern Warfare 2 Campaign Remastered: Fixed a possible GPU hang. (#3884)
  • Diablo 4: Work around an issue where the game does not start if an integrated GPU is exposed.
  • The Sims 4: Work around a use-after-free bug in the game's D3D11 renderer for real this time. (#4360)
  • Vindictus: Work around potential rendering issues caused by uninitialized constant buffer data. (#4405, #4406)
  • Yakuza 0 and Yakuza Kiwami: Fixed a regression introduced in DXVK 2.4.1 that would cause these games to lock up on start. (PR #4297)

Miscellaneous changes

  • An SDL3 backend was added for dxvk-native. (PR #4326, #4404)
  • Fixed an issue introduced in DXVK 2.4.1 which would lead to error messages about failed buffer creation.
  • Fixed a long-standing issue where overlapping occlusion queries would lead to incorrect Vulkan usage. (#2698)
  • Fixed a rare issue wherein timestamp queries would not be tracked correctly and could read incorrect data.
  • Fixed various other issues that led to Vulkan validation errors in games such as Dishonored 2, Tales of Arise and The Sims 4.
  • Fixed various issues with MSVC builds. (PR #4444)
  • Disabled a workaround for boken render target clears on Nvidia drivers prior to version 560.28.03 on unaffected drivers.
  • If supported, VK_EXT_pageable_device_local_memory is now used to enable better driver-side memory management.
[-] Atemu@lemmy.ml 60 points 3 months ago

the idea of putting people before profit feels increasingly radical

What. The. Fuck.

67
submitted 3 months ago by Atemu@lemmy.ml to c/linux@lemmy.ml
245
submitted 3 months ago by Atemu@lemmy.ml to c/linux@lemmy.ml

@brjsp thanks again for submitting the concern here. We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients' dependency on sdk-internal didn't change but that's okay now because they have licensed sdk-internal as GPL.

The sdk-secrets will remain proprietary but that's a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn't promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn't even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That's pretty sad.

220
submitted 3 months ago by Atemu@lemmy.ml to c/opensource@lemmy.ml

@brjsp thanks again for submitting the concern here. We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients' dependency on sdk-internal didn't change but that's okay now because they have licensed sdk-internal as GPL.

The sdk-secret will remain proprietary but that's a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn't promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn't even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That's pretty sad.

40
submitted 3 months ago by Atemu@lemmy.ml to c/linux@lemmy.ml

cross-posted from: https://lemmy.ml/post/21519137

I recently switched from a MBP to a Framework 16 as my primary laptop and one thing I immediately noticed was that I was unable to stop kinetic scrolls in Firefox by laying my fingers onto the touchpad. It'd just slide by unimpeded. You could work around this by counter-scrolling a little rather than holding still which is how I've been coping with it but it's suboptimal to say the least.
(As are many things in the Linux touchpad experience. Linux desktop developers really ought to use a macbook for a little to get a sense for how to do this properly.)

This was caused by Firefox' use of GDK3 to implement its windowing and input needs which does not support hold gestures.

GDK4 does support them but, as I understand it, a port of Firefox to GDK4 would be a ton of work and there isn't really much desire for it as GDK4 doesn't offer many real advantages over GDK3 as Firefox doesn't use classical GTK widgets or anything and only really uses it for basic input/output primitives.

A backport to handle hold gestures in GDK3 too was attempted but, in classic GNOME fashion, it was rejected.

The implementation now somehow gets events from the touchpad directly via wayland somehow from what I could gather but if it works, it works.

You can try this out in the latest nightly builds.

[-] Atemu@lemmy.ml 74 points 10 months ago

I am ashamed of GitLab.

Don't be. Gitlab has to comply with the law.

It's the law that's broken, not Gitlab.

It’s absolutely ridiculous they took it down even though Nintendo didn’t DMCA the Suyu project directly.

Um, no. If shitty corpo X (ab)uses the DMCA to send you a takedown notice for some project and you also host a fork of the same project, you must take down the fork too.

"You see, while this might be the exact same code, the name is totally different, so we don't have to take it down!" will not hold up in court.

Whether the DMCA request is valid or not is an entirely separate question. You must still comply or open yourself up to legal liabilities.

The process to object to the validity of the request is included in the screenshot.

[-] Atemu@lemmy.ml 60 points 10 months ago

Depends on how much of our needs would be covered. Not needing to work to survive is different from not needing to work to live a comfortable life which is again different from living a luxurious life.

[-] Atemu@lemmy.ml 79 points 11 months ago

At least they now allow passwords over 8 characters (yes, serious).

Are you 100% certain they don't just truncate your password to 8 characters?

[-] Atemu@lemmy.ml 60 points 11 months ago

Why do you feel the need to change phones? Pixel 6 Pro should still be plenty good enough.

If its stock ROM bothers you, you're in luck because Pixels are surprisingly hackable and it's very easy these days.

See i.e.: https://grapheneos.org/
No need to worry about Google services, they work: https://grapheneos.org/usage#sandboxed-google-play

[-] Atemu@lemmy.ml 60 points 1 year ago

Distro doesn't really matter here. Choose any that you like.

[-] Atemu@lemmy.ml 58 points 1 year ago

The link you posted is a post by a mod announcing that they will enforce the policy given to them by the LW admins.

From the modlog I can tell that (presumably) you posted a text post to !politics@lemmy.world about the policy that was then removed.

If you're posting to !politics@lemmy.world, such posts would obviously be removed because that's A. not on topic (that'd be a topic for !lemmyworld@lemmy.world. ) and B. not a link to an article. The latter is also the reason given for the removal.

Stirring up drama over absolutely nothing usually ends up hurting someone. Could you not?

[-] Atemu@lemmy.ml 76 points 1 year ago

What a terrible graph. That "huge" spike is a mere 0.5% increase. That might as well be noise.

Don't believe any graph whose y-axis starts at any value but 0 people.

[-] Atemu@lemmy.ml 58 points 1 year ago

And also tar -the fuck is in this file

[-] Atemu@lemmy.ml 60 points 1 year ago

I was wondering what Twitter had to do with gaming...

[-] Atemu@lemmy.ml 87 points 2 years ago

The cause is a 502 from lemmy.

Jerboa's handling of that error is also terrible but that's another issue.

view more: next ›

Atemu

joined 4 years ago
MODERATOR OF