Atemu

joined 5 years ago
MODERATOR OF
planetside
kagi
sorted by: new top controversial old
Experiences with different gearing on a 6-speed Brompton? in c/[email protected]
[–] [email protected] 2 points 2 months ago (1 children)

That is indeed a nice tool.

The default configuration of 13/16T also provides quite even spacing though. The more significant difference is that the 12T in the back require a 44T chainring for similar development as 13T + 50T and that extends the lowest gear from 2.65 to 2.49.

This is all nice and all but my problem is that it doesn't tell me how significant that difference actually is in the real world; I don't know how the 0.25 delta would actually manifest itself in a way where you'd feel an appreciable improvement in climbing hills.

Backups: Am I doing this right? in c/[email protected]
[–] [email protected] 1 points 4 months ago

There's also the option of just leaving an offline disk at someone's and visiting them regularly to update the backup.

Having an entirely offline copy also protects you/mitigates against a few additional hazards.

Immich: opinion revised in c/[email protected]
[–] [email protected] 5 points 4 months ago

If you don't process any user data beyond what is technologically required to make the website work, you don't need to inform the user about it.

Why is it so difficult to know if a game is goig to run on your system? in c/[email protected]
[–] [email protected] 1 points 4 months ago

Note that even with this it'll be quite likely that games don't work. WineD3D is much less compatible than DXVK.

You need a device that can do Vulkan properly. The best for that are AMDGPUs and Nvidia ones but I wouldn't recommend the latter. Newer Xe Intel GPUs should also work but they're quite a bit behind anything AMD has to offer in terms of performance.

The newer of your GPUs meanwhile is a design from ~2015. Vulkan released in 2016. Just to get you an idea.

The issue here is not Linux, it's that neither of your GPUs was made for modern gaming. On windows that might sometimes work, especially with games targetting older graphics APIs that your GPUs were made with in mind but on Linux everything is Vulkan (a very modern graphics API), even games that only use older APIs.
A modern Vulkan-capable card is a requirement for painless gaming on Linux.

Kagi Introducing Fair Pricing in c/[email protected]
[–] [email protected] 6 points 5 months ago

On the one hand yes but on the other hand this would also kind of set wrong incentives: to use Kagi search less because you'd need to pay more.
That's not an incentive they or you would want.

I think what I'd like is how my mobile carrier handles their data limits: It's not an entirely fair comparison because in that case, contrary to Kagi, there is no real cost associated with my degree of usage of the service, making them entirely arbitrary and unnecessary but besides that the unused data rolls over to the next month and that's something Kagi could mirror.

I hover around 600-1000 searches per month but sometimes exceed 1000. If I could pay for 1000/month and accumulate a little buffer in the months where I search less, that would work for me. Though perhaps I'd still want to just simply pay for unlimited usage for peace of mind.

Kagi Introducing Fair Pricing in c/[email protected]
[–] [email protected] 4 points 5 months ago (1 children)

This sounds like FUD. Do you have a source for that?

As a paying member, I know that they started charging (and presumably transferring) VAT last year.

Before that, they claimed they were simply too insignificant to even be eligible for VAT.
I looked it up and there appears to be an exception for such cases where VAT is charged in the company's jurisdiction rather that the customer's (it's usually the other way around) until you reach 10000€ annual turnover. Information on this is extremely intransparent however, so this might be wrong.

Kagi Introducing Fair Pricing in c/[email protected]
[–] [email protected] 17 points 5 months ago* (last edited 5 months ago) (2 children)

They do. The $10/month search plan is unlimited.

The only LLM stuff in their search product is the quick answers which can be turned off and page summaries which you have to explicitly click on in a submenu in any case.

As someone aware of how limited LLMs are, I've actually found both of these features to be useful for gauging whether a site is worth visiting or not at times which is part of the core feature set of a search engine IMHO.

A good while back they claimed that Google search index fees make up the vast majority of their costs, so I doubt any of your money is going towards LLM BS unless you actually pay for their assistant product.
I doubt Google has given them any discounts since then.

I'd expect the development of all of their product to be mostly funded by VC. If they can get VC idiots who fell for the """AI""" hype to subsidise building an actually useful thing (the search product), that's a win in my book, even if they also have to build the AI crap on the side to keep said VC idiots happy.

Full Android image backup in 2025? in c/[email protected]
[–] [email protected] 7 points 5 months ago (1 children)

Even with root it's not anywhere near trivial.

You can't, for instance, make a backup of the userdata partition block device and expect to be able to restore it because it must be decrypted by a key in the phone's security module that gets wiped when you boot a new ROM.

Oregon bill seeks to ban high-speed e-bikes from bike lanes and sidewalks in c/[email protected]
[–] [email protected] 1 points 5 months ago

While velocity is certainly the larger contributor, it's not like mass is insignificant either. Especially for the cargo bike case where even unloaded the mass difference requires a ~5km/h change in velocity for equal kinetic energy.

When you get to very high absolute velocities, mass becomes less and less significant but we're very much at the low end here in that regard.

Oregon bill seeks to ban high-speed e-bikes from bike lanes and sidewalks in c/[email protected]
[–] [email protected] 5 points 5 months ago (2 children)

With E-bikes it's not just the "unnaturally" fast speed but also weight and that's doubly important for powered cargo bikes.

Speed limits don't really make sense here though. What determines the amount of damage inflicted in a collision or how easy it is to avoid a collision by breaking is kinetic energy; that's what needs to be limited.

I'd just base this around what a "normal" human on a "normal" bicycle can do on flat ground with reasonable human power alone: e.g. 70kg human on a 10kg bicycle doing 25km/h. That's 80 kilogram × (25 kilometre / hour)² = 3858.02 J of kinetic energy.

Now we can assume e.g. a 20kg e-bike and calculate backwards: sqrt(3858.02 joule / (70 kilogram + 20 kilogram)) = 23.5702 km/h
Or with a 50kg cargo e-bike: sqrt(3858.02 joule / (70 kilogram + 50 kilogram)) = 20.4124 km/h.

Ideally cargo bikes would also factor measured load into them. If you carried an additional 50kg, it should only power up to 17.1498 km/h for instance.

What conditions would be "safe" under "normal" circumstances and how heavy you assume people to be are debatable and dependent on where you are (welcome to NA, +10kg avg. weight) but the mechanism should be the same.
We need to define some limit of kinetic energy that is reasonably safe for pedestrian and bicycle collisions and in line with what typical human on an unpowered bicycle would net you. Powered bicycles (or any other powered vehicle for that matter) then need to enforce that limit by way of cutting off power once the maximum kinetic energy is reached.

Experiences with different gearing on a 6-speed Brompton? in c/[email protected]
[–] [email protected] 2 points 6 months ago (1 children)

I tried to relate the limited niche where having closer together gearing makes a noticeable difference

You appear to be misunderstanding. This isn't about making gearing be closer together, this is about increasing the range of the gearing by making the low end lower and only reducing the high end by a little.

If anything, the configurations I wrote about would make gear spacing less even as the default is quite nicely spaced.

What I need to know is whether the change in the low end is actually noticeable in an uphill scenario and by how much.

So I prefer to have as wide as my drivetrain supports. If I have any choice, I prefer a tighter set of low gears and a bailout final cassette cog.

It's the same for me I think. I'd prefer some variety of low gears for uphills and some variety for relatively flat ground. I don't very much care what's in between as long as it's not too far apart.

When I start riding, I usually use one of the lower gears for half a turn and then immediately switch the hub from 64% to 100% (skipping the gear in between) which is a jump from 2.64m to 4.14m or 3.25m to 5.10m and then usually up to 5th gear (6.49m) for a bit and then the 6th gear when conditions allow.

I wouldn’t worry about the total, and would start with the widest cassette that will work with your current setup. Then I would only change the front chainring if you still feel a lack of top speed.

This again appears to be a misunderstanding: This is a 6-speed Brompton.

6-speed here means 6 gears total, including the hub.

The gearing is as follows:

  • Hub with 3 fixed ratios (64%, 100%, 157%)
  • Derailleur between two sprockets that can be equipped with a maximum of 17 teeth due to size constraints
  • One chainring (no derailleur)

I get to choose the two sprockets and the chainring. That's it; there is no wider cassette that physically fits this frame.

The reason for changing the chainring is merely to shift the gearing down which isn't possible by changing the sprockets because a sprocket larger than about 17T will physically not fit. Again, this is a Brompton with tiny 16" wheels that folds down to suitcase size.

Experiences with different gearing on a 6-speed Brompton? in c/[email protected]
[–] [email protected] 1 points 6 months ago (3 children)

Right but I do like to ride fast when possible. It's not for competitive edge or anything; it's just comfortable.

The main thing I want answered is whether the difference in metres of development in the low end actually makes a difference and how significant they are in practice.

8
Experiences with different gearing on a 6-speed Brompton? (lemmy.ml)
 

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?

1
Kobo handwriting troubles with mathematical notation (lemmy.ml)
submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]
0 comments fedilink
 

I recently got my Kobo Elipsa 2E and it's better than I expected, especially the simplicity of OS and how well handwriting generally works were a surprise to me.

Given that its handwritten notes features are surprisingly capable, I've been trying to use it to take notes for learning physics but quite soon ran into an issue in trying to use the advanced notebook:

In physics, there's a notation where you can write dx/dt as an x with a dot above it (ẋ), adding more dots the more often you take the derivative w.r.t. time though you typically only need 2 max. The handwriting recognition for formulas does not know this notation however and therefore converts any attempts to stupid stuff instead.

Additionally, I quite frequently write sentences that also contain some "math symbols" such as δ or θ or even just mathematical expressions such as L(x). Formula fields would recognise these just fine but no such luck with regular text fields; it tries to make normal letters or words out of these.
The maths formula mode cannot be used for annotating equations either as it garbles words into symbol structures.

The fall-back would be to just use raw drawing plots but my handwriting is quite poor and I'd rather have text because that really works quite well otherwise. I could write text mode until I need a sentence with a symbol in it but I don't know ahead of time whether I'll need it and by the time I know, it's already too late and I'd need to write the entire sentence again inside a raw canvas.

Are there any solutions or potential workarounds to my problems?

Is it possible to make the formula recognition aware of this notation somehow? I'll likely need further such niche notations in the future too.

Is it perhaps possible to have sections of text (or even formulas) that contain small raw canvases which don't get converted to text? That would also be a nice escape hatch.

Is there an alternative note-taking app one could side-load that works better perhaps? The hardware is surprisingly capable as mentioned; these issues are purely in software.

1
Kobo handwriting troubles with mathematical notation (lemmy.ml)
submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]
0 comments fedilink
 

I recently got my Kobo Elipsa 2E and it's better than I expected, especially the simplicity of OS and how well handwriting generally works were a surprise to me.

Given that its handwritten notes features are surprisingly capable, I've been trying to use it to take notes for learning physics but quite soon ran into an issue in trying to use the advanced notebook:

In physics, there's a notation where you can write dx/dt as an x with a dot above it (ẋ), adding more dots the more often you take the derivative w.r.t. time though you typically only need 2 max. The handwriting recognition for formulas does not know this notation however and therefore converts any attempts to stupid stuff instead.

Additionally, I quite frequently write sentences that also contain some "math symbols" such as δ or θ or even just mathematical expressions such as L(x). Formula fields would recognise these just fine but no such luck with regular text fields; it tries to make normal letters or words out of these.
The maths formula mode cannot be used for annotating equations either as it garbles words into symbol structures.

The fall-back would be to just use raw drawing plots but my handwriting is quite poor and I'd rather have text because that really works quite well otherwise. I could write text mode until I need a sentence with a symbol in it but I don't know ahead of time whether I'll need it and by the time I know, it's already too late and I'd need to write the entire sentence again inside a raw canvas.

Are there any solutions or potential workarounds to my problems?

Is it possible to make the formula recognition aware of this notation somehow? I'll likely need further such niche notations in the future too.

Is it perhaps possible to have sections of text (or even formulas) that contain small raw canvases which don't get converted to text? That would also be a nice escape hatch.

Is there an alternative note-taking app one could side-load that works better perhaps? The hardware is surprisingly capable as mentioned; these issues are purely in software.

1
E-reader for manga that isn't enshittified and doesn't spy on me? (lemmy.ml)
 

I've been gifted a Sony PRS-T3 over a decade ago. I've recently gotten into reading again and used it to read a manhwa/webtoon/web novel (or whatever the Korean ones are called) and most recently a light novel.
It's functional and perhaps even decent (especially given its age) but my main gripes with it are:

  • Size: It's much too small to fit an entire manga page with readable text, so you need to use hacks like kcc which is suboptimal. I'd like the display to be the size of a typical manga or slightly larger.
  • Lack of customisation: It has this ugly indented paragraph style in books which I don't like and the selection of fonts aswell as font rendering isn't great.
  • Artifacts in images: When anything more complex than text is on display (and even with text it's subtly noticeable), you always see ghosts of the previous image. This is perhaps the most critical flaw for the purpose of reading Manga. Image quality in pictures isn't great to begin with either.
  • Slow: Page turning is fast enough but doing anything else it turns into a slog. Switching between "books" (the manhwa had each chapter as a separate book) was annoying to say the least.
  • Bad UI: It's just generally poorly organised and common things required way too many interactions (which, mind you, are slow).
  • No light: I appreciate not requiring a light but I'd sometimes like to have the option.
  • Ergonomics: It's light but not very comfortable to hold. I think I've seen readers that have a thicker end on one side so that you can better hold onto it? I'd appreciate advice here.

It's also showing its age; I had to tape the lid already as the material started to disintegrate.

I did very much appreciate how simple it is though. Open the lid, it immediately turns on, (I enter my PIN) and I can continue to read my book where I left off. Just like a real book but more convenient. I'd like to retain that property.
Battery life is also still great, even after all these years. I can close the lid and leave it sitting around for weeks and return to it with barely any battery drained. Again like a book where I don't have to worry about any battery charge either.
It's also quite light which I like, though a little bulky but totally acceptable.

Deal breakers:

  • Enshittification: If the primary purpose of the reader is to sell books rather than read them, I don't want it.
  • Espionage: I don't want Google, Amazon or anyone else spying on when I read what books. I'm probably going to have its networking off anyways but I don't want anyone spying on me offline either.
  • Gesture-only page navigation. Physical buttons please.
  • Ads of any kind.
  • Any power/data connector other than USB-C

I don't care for DRM. I'll be loading epubs onto the reader from another machine.

I don't think I need colour. I mean, it'd be nice I guess (especially for manhwa, those appear to frequently be coloured?) but if that compromises on greyscale or text clarity, no thank you. I also don't know whether e-ink can reproduce colour accurately enough that it's even an upgrade over greyscale and doesn't just look ugly.

FOSS firmware would be amazing but my research suggests that's not really a thing? I'd settle for a decently customisable proprietary firmware as long as it doesn't suck donkey balls or needs to be connected to the internet.

I don't need to draw on it.

Price is secondary but I don't like wasting money either.

I'm in Germany/EU.

I don't have a single clue about the e-reader market. I'd appreciate any advice on what I want and, more importantly, don't want given the constraints and desires I described.

36
NixOS 24.11 released (nixos.org)
1
Release scrcpy v3.0 · Genymobile/scrcpy (github.com)
 

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
Release scrcpy v3.0 · Genymobile/scrcpy (github.com)
 

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):

96
Release scrcpy v3.0 · Genymobile/scrcpy (github.com)
 

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):

33
Release v0.6.0 · ilya-zlobintsev/LACT (github.com)
 

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
1
Release v0.6.0 · ilya-zlobintsev/LACT (github.com)
 

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
1
DXVK Version 2.5 (github.com)
 

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.
1
VMware Workstation Shifting From Proprietary Code To Using Upstream KVM (www.phoronix.com)
view more: next ›