fixing a bunch of broken stuff I think
This commit is contained in:
parent
0dbc3ead0e
commit
8bace887a2
1551 changed files with 299 additions and 57481 deletions
|
|
@ -1 +0,0 @@
|
|||
<!-- SC_OFF --><div class="md"><p>Hello everyone. Hoping to get some feedback on some general observations I've made after recently changing out some hardware.</p> <p>For the past 6 months or so I have been using Arch full time, using KDE Plasma and X11. Up until a few days ago, I had been using an Nvidia RTX 2080.</p> <p>Unfortunately, I encountered a hardware failure (a badly-soldered VRM capacitor came off with the thermal-pad when I removed the heatsink to apply thermal paste) and have switched to using an old AMD R9 270x I had from years ago.</p> <p>I'm hoping to repair the Nvidia card by replacing the capacitor or sending it to the manufacturer, but in the meantime I'm using this rather old AMD card.</p> <p>I'm using the AMDGPU drivers via Mesa, with the following output in <code>lscpi -v</code>:</p> <p><code>01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X] (prog-if 00 [VGA controller])</code> <code>Subsystem: ASUSTeK Computer Inc. Device 04a1</code> <code>Flags: bus master, fast devsel, latency 0, IRQ 136</code> <code>Memory at c0000000 (64-bit, prefetchable) [size=256M]</code> <code>Memory at df300000 (64-bit, non-prefetchable) [size=256K]</code> <code>I/O ports at e000 [size=256]</code> <code>Expansion ROM at 000c0000 [disabled] [size=128K]</code> <code>Capabilities: <access denied></code> <code>Kernel driver in use: amdgpu</code> <code>Kernel modules: radeon, amdgpu</code></p> <p>The observations I've had so far:</p> <ul> <li>Compositor performance is vastly superior using AMD drivers. Windows move and animate far more smoothly. I use a 165hz monitor. This is apparent on both devices, but on the AMD card, compositor is virtually free of artifacts and lag, whereas on the Nvidia device, occasional stutter would occur. I've heard that Nvidia's proprietary drivers have issues with X11.Is there configuration that can be done to mitigate this, or is it simply a fact of the driver? I did review the Nvidia Troubleshooting article on the wiki, and had all mitigations listed applied before switching cards.</li> <li>Firefox performance is drastically better on AMDGPU. I have previously enabled all the proper WebRender settings per the troubleshooting article. With the Nvidia card, I had to have YouTube or Netflix open in a Chromium instance. With any video playing in Firefox, other Firefox windows experienced heavy lag when animating or scrolling. With no settings changes, this is entirely absent on AMDGPU. Additionally, even without video playing, Firefox is far smoother using the AMD device than the Nvidia.</li> <li>Gaming performance in Linux on the AMDGPU is drastically worse than using the same card on Windows. For comparison, in the Lord of the Rings online (an old game), I get about 25 FPS on max settings. Windows gets 140+ FPS on identical settings during identical tests.This isn't really something I'm trying to fix, as I'm totally sure this is a result of the card being ancient and driver support being minimal. That said, if anybody has any tips, I'd love to hear them.</li> </ul> <p>​</p> <p>Given the AMD card's age, I'm certain these issues are related to driver compatibility or configuration. Still, I didn't see anything about these differences on the wiki, and I'm curious if the community has any more knowledge on the subject.</p> <p>The primary reason for my asking is that (whenever this chip shortage is no longer a problem) I'm entertaining the idea of getting an AMD card. Barring this hardware failure, I would've been content to remain on that 2080 for another 5 years or so. I don't really care about bleeding-edge performance (I mostly just play old MMO's and indie titles), and if an ancient AMD card can offer me a better day-to-day experience in my preferred operating system, that's a very powerful factor for me.</p> <p>​</p> <p>Edit: I realized this might come across as a fanboyish Nvidia hate-post. I want to clarify, that's not the case. I have virtually no brand loyalty, and would be perfectly content getting my Nvidia card fixed and working as well as this old AMD card does for day-to-day stuff, since it would mean not having to buy a new gpu. I was just surprised by the differences and wanted to solicit feedback.</p> </div><!-- SC_ON -->   submitted by   <a href="https://www.reddit.com/user/Aerlock"> /u/Aerlock </a> <br/> <span><a href="https://www.reddit.com/r/archlinux/comments/q6ropz/arch_amdgpu_vs_nvidia_observations/">[link]</a></span>   <span><a href="https://www.reddit.com/r/archlinux/comments/q6ropz/arch_amdgpu_vs_nvidia_observations/">[comments]</a></span>
|
||||
|
|
@ -1 +0,0 @@
|
|||
<!-- SC_OFF --><div class="md"><p>After seeing a few YT videos and reading the Arch wiki about secure boot, I understand it can be useful to prevent kernel tampering. However it does seem like a lot of effort and by using 3rd party key solutions, it wouldn't make things any more secure right? If someone tampered with the kernel when booted, it can probably even sign it perfectly fine?</p> <p>Anyway I'm using systemd-boot and the given solutions seems to be a bit mixed either. The most easy way seems to sign your own keys by adding prehooks that run on every kernel upgrade?</p> <p>I would like to use SB to upgrade Windows, but with all those things considered I simple could just run W11 in a VM instead.</p> </div><!-- SC_ON -->   submitted by   <a href="https://www.reddit.com/user/improve-me-coder"> /u/improve-me-coder </a> <br/> <span><a href="https://www.reddit.com/r/archlinux/comments/q8kcet/is_secure_boot_worth_the_effort/">[link]</a></span>   <span><a href="https://www.reddit.com/r/archlinux/comments/q8kcet/is_secure_boot_worth_the_effort/">[comments]</a></span>
|
||||
|
|
@ -1 +0,0 @@
|
|||
<!-- SC_OFF --><div class="md"><p>Hi guys!</p> <p>I'm using xournal++ to write my notes with my pen on my laptop. It was normally working like whenever I put the pen near to the screen, the cursor moves to the pen, even if my hand is on the screen.</p> <p>Now I just did an update with <code>yay</code> by just wirting <code>yay</code> in my shell. After finishing the update, I just rebooted my system. To my surpise when I opened xournal++, my cursor didn't move to my pen, when I first put my hand on the screen. I needed to touch somewhere else on the screen with my finger first to be able to move the cursor.</p> <p>Do you have an idea how I can get back the old behaviour, that it focuses always focuses the pen whenever I get near to the screen with the pen?</p> <p>I'm using the <code>libinput</code> and <code>xf86-input-wacom</code> packages if that can help you.</p> </div><!-- SC_ON -->   submitted by   <a href="https://www.reddit.com/user/TornaxO7"> /u/TornaxO7 </a> <br/> <span><a href="https://www.reddit.com/r/archlinux/comments/rur5hv/how_to_fix_tochscreen/">[link]</a></span>   <span><a href="https://www.reddit.com/r/archlinux/comments/rur5hv/how_to_fix_tochscreen/">[comments]</a></span>
|
||||
Loading…
Add table
Add a link
Reference in a new issue