SteveTech

joined 1 year ago
[–] SteveTech@programming.dev 2 points 3 months ago

Along with VRR over HDMI not being well supported, sometimes the monitors own EDID is a little buggy and Linux can't guarantee VRR will work properly.

I wrote a blog post a while ago on fixing EDIDs, but it was pretty much a guessing game on what to change: https://stevetech.me/posts/force-enable-vrr-edid

I've had to do that with both Samsung and MSI monitors so far. If you'd like to post your EDID, I could check it myself with what I know.

[–] SteveTech@programming.dev 3 points 3 months ago

Epic!

I've never seen that on modern AMD stuff that uses radv, but I'm sure it's probably fine.

[–] SteveTech@programming.dev 3 points 3 months ago (3 children)
[–] SteveTech@programming.dev 3 points 3 months ago* (last edited 3 months ago) (7 children)

Oh whoops yeah there is, run sudo update-grub.

But otherwise that config looks correct.

[–] SteveTech@programming.dev 5 points 3 months ago* (last edited 3 months ago) (9 children)

Cool, you're going to have to enable Sea Islands (CIK) support for amdgpu. You should just have to add radeon.cik_support=0 amdgpu.cik_support=1 to your kernel parameters. You're probably using GRUB so to do that you'll need to run sudo nano /etc/default/grub to edit it's config file, then add the above to the end of GRUB_CMDLINE_LINUX_DEFAULT (keep it in the quotes, but space seperated from the previous parameter). Then reboot and hopefully Vulkan works!

Alternatively, there's a section on the Arch Wiki for this, it should work fine for Mint too: https://wiki.archlinux.org/title/AMDGPU

[–] SteveTech@programming.dev 5 points 3 months ago (11 children)

Could you post the output of vulkaninfo including any errors that it might also print.

If it's not shown, what GPU do you have?

Also run lspci -k, is your GPU using amdgpu or the old radeon driver?

[–] SteveTech@programming.dev 1 points 3 months ago

I think some people also use power_save=0 which would, but my understanding is 11n_disable=8 enables aggregating transmit packets together, which impacts latency but improves upload speed.

[–] SteveTech@programming.dev 1 points 3 months ago (1 children)

Do you have any FF extensions that might be interfering somehow?

[–] SteveTech@programming.dev 1 points 3 months ago

The HTTPS certs are designed to prevent MITMing, but if it's still a worry or the domain is blocked by DNS, you can manually find the IP and add it to your hosts file instead.

[–] SteveTech@programming.dev 1 points 3 months ago* (last edited 3 months ago) (1 children)

A reverse proxy by itself doesn't do much security wise. You could possibly setup some sort of authentication, attempt blocking, and rate limiting (in the reverse proxy, don't trust the DVR), but it'll probably also break the DVR even more.

There's bots that port scan and specifically target all sorts of stuff, and DVRs are a very common target. With a VPN in the way, there's no way of knowing what's there. A VPN also shouldn't break the web UI.

[–] SteveTech@programming.dev 8 points 3 months ago (5 children)

I really wouldn't expose a DVR to the internet, and especially not RTSP, those sorts of things get brute forced all the time, and you can find websites full of hacked cameras.

What I would do is run a VPN server (maybe Wireguard) on your Pi, and VPN in when you want to look at your cameras.

[–] SteveTech@programming.dev 9 points 3 months ago

It's probably blocked for whatever reason (maybe less than 90 days old?)

My work and Uni do the same thing, they don't do full SSL inspection, so most websites don't need a custom certificate authority; but if the SNI is blocked then they need a custom certificate to hijack and display a blocked message, most browsers will detect this as a MITM and display a not secure message instead.

view more: ‹ prev next ›