Personally, I've been happy using an LG TV for a single monitor setup. I have had to switch to KDE Plasma v6 for better font rendering given its unusual OLED pixel layout, as well as for native HDR support. But it's been nice to have a large physical font while still at default DPI. Although, I wouldn't't mind upgrading to 8K later when they get affordable, as the smallest 4K TVs at 42" happen to push the physical DPI down towards that of just 1440p panel.

https://programming.dev/comment/7921093

I'm using a recent 42" LG OLED TV as a large affordable PC monitor in order to support 4K@120Hz+HDR@10bit, which is great for gaming or content creation that can appreciate the screen real estate. Anything in the proper PC Monitor market similarly sized or even slightly smaller costs way more per screen area and feature parity.

Unfortunately such TVs rarely include anything other than HDMI for digital video input, regardless of the growing trend connecting gaming PCs in the living room, like with fiber optic HDMI cables. I actually went with a GPU with more than one HDMI output so I could display to both TVs in the house simultaneously.

Also, having an API as well as a remote to control my monitor is kind of nice. Enough folks are using LG TVs as monitors for this midsize range that there even open source projects to entirely mimic conventional display behaviors:

• https://github.com/JPersson77/LGTVCompanion
• https://github.com/cali-95/LGTVLinuxCompanion

I also kind of like using the TV as simple KVMs with less cables. For example with audio, I can independently control volume and mux output to either speakers or multiple Bluetooth devices from the TV, without having fiddle around with repairing Bluetooth peripherals to each PC or gaming console. That's particularly nice when swapping from playing games on the PC to watching movies on a Chromecast with a friend over two pairs of headphones, while still keeping the house quite for the family. That kind of KVM functionality and connectivity is still kind of a premium feature for modest priced PC monitors. Of course others find their own use cases for hacking the TV remote APIs:

• https://youtu.be/io_AFseYleE
• https://youtu.be/76wAEJOdBq8

Didn't know about this case history with Nintendo, nor the name for the common exploit used:

• Game Genie
  • https://en.wikipedia.org/wiki/Game_Genie
• Fusée Gelée exploit
  • https://switch.homebrew.guide/gettingstarted/choosinganexploit.html#fusee-gelee
  • https://medium.com/@SoyLatteChen/inside-fus%C3%A9e-gel%C3%A9e-the-unpatchable-entrypoint-for-nintendo-switch-hacking-26f42026ada0

That's would be one long commute to the job site. Likely only a one way trip. I guess if cryostasis every becomes viable for human space flight, you'd have a better chance living long enough to catch up to the craft, but then you'd probably have the hassle of getting reassigned to a new office team, given all your old colleagues would have long retired, and who would really want to start patching hardware in production with a support crew you only just met after waking up. Sounds like a tough remote working environment, with all the cons in a aynchronous workplace, but with none of the perk in working from home.

It looks like another project outlined in the Bevy blogs that is also listed in steam (planned for release 2024) is Tiny Glade:

• https://store.steampowered.com/app/2198150/Tiny_Glade/
• https://steamcommunity.com/app/2198150

Thanks so much for your hard work and the terrific beta release!
Here's to the success of Lemmy, Sync for Lemmy, and the rest of the Fediverse,
Cheers! 🍻

Cool! Could you share that link with the !cobol@programming.dev community?

Also, be sure to checkout this community: !learn_programming@programming.dev

This also ties well into @canpolat@programming.dev 's recent post yesterday, about validating or verifying emails. Check this timestamp and yesterday's post:

• https://youtu.be/mrGfahzt-4Q?t=990
• https://programming.dev/post/407741

I think there are some user scripts folks are developing via browser extensions, but perhaps it'd be better to mainline the kind of features these ticket are tracking:

• https://github.com/LemmyNet/lemmy/issues/3259#issuecomment-1605708143

1. move topic collection into a new community

I think it would be hard to concretely categorise what should go into a new hypothetical !main(?) vs !programming given such a !main should still fall under the scope of the theme of the instance's name, programming. It could worsen the indecision for first time posters, or those trying to understand the applicable nuance between the two. Perhaps the community could keep with the classic montra "I know it when I see it" to keep posts on brand.

Also, IMO, trying to change the general default community from !programming to something else would be like trying to close the barn door after the horse has bolted, or like trying to change horses in midstream, given !programming is already our largest community.

Yeah, it was real nice once the kernel modules for PS DS3/4 finally shipped with Android's mainline. Although, it's still a pain that one needs to recompile the module to disable the rumble or LED when games using the device do not expose user level override settings.