• 0 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: July 20th, 2023

help-circle
  • This is not traditional VRR how we think of it. VRR how we think of it is changing the “frame rate” of the monitor to better suit the frame pacing of the received frames, this is not whats happening here. This is how things like freesync works. It takes your device framerate, say 60fps, and slows it down to better match the frame pacing of the content, say 48fps. Now the monitor doesn’t physically change states or anything, it just allows flexible updating to match the frame pacing.

    You don;t get this with this adaptive refresh rate method

    Here you are effectively getting a noop every refresh cycle it doesn’t need. It’s still good, but not as good as what most people think of as VRR (Freesync/vesa adaptivesync, gsync etc.). You are limited to the steps your display can output. For this to be useful you require a high refreshrate display like 120hz because each application needs to align with a frame refresh.

    IE. say you have a 24fps video, the display won’t change it’s frame pacing, but rather you get a noop every 4 frames and a refresh, (24 * 5). Now assume you have a 90hz display, 24fps has no solid divisor in 90fps, so you have to either wait for sync, or get tearing. The first one leads to judder (which can probably be mitigated using offset sync waits?) the second one is well, tearing.



  • specific parts. you need metal to withstand the pressures of the actual bullet to get a somewhat degree of reliability, so any pressure bearing part needs to be metal, everything else can be plastic, but the more metal the better. Now you can get some more basic designs with parts that you could fabricate at home, but a lot of the higher end designs require off the shelf gun parts.

    The “leading design” right now is the FGC-9 which is actually seeing a degree of use in myanmar(??). The design requires metal parts that could be feasible to fabricate at home. However it is shockingly easy, even in heavily restricted countries, to be able to order the metal parts.








  • It’s not really hacky as far as I know, it’s just the old status quo. On X applications could scale themselves if they have high DPI support, and that’s what KDE is allowing. And it works great. The vast majority of apps I use support high DPI on X, and they work perfectly fine on xwayland.

    It is legitimately a great experience using xwayland like this. A lot of apps I use, they look perfectly fine, they perform perfectly fine, and they’re not broken, which is a massive plus.

    Of course, this probably does break one or two apps out there. I’m not saying it’s a perfect solution. It’s far from it. But honestly, I think it’s a really good solution. It allows developers the ease and flexibility of developing for X11 if you don’t need Wayland’s features.

    Of course, you are still losing out. Having proper touch support is such an amazing feature with Wheland. Don’t get me wrong. I love a lot about Wheland. It’s just a pain in the ass to develop for. It is nowhere near as flexible as X11.







  • for anyone trying on a similar setup, Feel free to reach out on the bliss and waydroid matrix/telegram channels if you would like some more help. Blue archive JP seems to work fine under waydroid as a couple users report. and as for bliss, ping me (@Quackdoctech) in the telegram chat and we can work on trying to get nvidia to work. it seems hit or miss and we really need more nvidia users to help debug issues.

    as for waydroid issues, It might be best to wait to see if the work on A13 will remedy the situation, but we shall see.

    PS. I am the one who wrote qemu docs for bliss. also I highly recommend using the new bliss images, the Android 12L ones. not sure if OP is author, but if not feel free to try and forward it to them