Check the time and date on the PC is correct and Windows updates have been applied.
Check time/date is good idea.
Maybe check Windows if certificate âVerisign Class 3 Public Primary Cerfifikation Authority -G5â is present/trusted.
Iâm using Win 10 (Czech) just fine.
Redhat certificate has hash SHA-1, isnât it issue (some MS deprecation policy)?
thanks for the help guys. Date and time is correct.
Where can I look for âVerisign Class 3 Public Primary Cerfifikation Authority -G5â ?
ok found it via this tutorial:
https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in
Verisign is under certificates but when I clicked proprties I see it is not being used for signing drivers. Any ideas hwo can I change this setting?
The tutorial linked above show howto open it in mmc , but it saves the setting to external file.
edit: Iâm even more confused. While using mmc method the Versign is not marked as being used for signing drivers. But when I access the certificate through IE it is. ArggggghhhhâŚ
The certificate it is signed with is for signing drivers, verisign validates that the certificate used to sign the driver with is valid, its a chain.
Ie. Verisign Cert -> ⌠any intermediates -> RedHat Cert
Only the final cert is capable of signing drivers. If anything in that chain is broken (doesnât verify, or missing) windows canât verify the driver.
Driver signing root certificates are compiled into the windows kernel and can not be altered/changed. Since you canât make it work it is very likely something is very wrong with your Windows installation.
not sure it is Windows installation issue itself - as mentioned I have this on 2 separate machines. On both I couldnât verify ivshmem driver.
Anyways Iâve rebooted and now in certificates panel in both IE and mmc I see the same entries. Still no luck with ivshmem driver.
So I did what worked on my home machine - disabled secure boot in VM and then disabled integrity checks with bcdedit. A nasty workaround but at least it got me a step further.
Iâve tried a11 host - closes shortly after starting it (and the process gets removed from task manager). Iâm not experiencing this with a10 host - so I guess Iâll recompile linux client to match this version.
In Command Prompt run
looking-glass-host.exe -f
and post its output here.
Looks like LG Bleeding Edge has problem with change resolution of GuestOS? Must be restarted both (host and client).
So gnif mentioned not to report on bugs if youâre not using a tagged release unless you can help debug or even better help fix issues.
Interesting. This explains why self signed drivers donât pass Windows checks. I knew they donât work unless you enable test mode in the OS but itâs nice to have a technical explanation as to why.
Focus on NV12 and I422, Those are the main chroma compressed video formats that work good with OBS. I444 might be more expensive computationally with no benefit in image quality or bandwidth over RGB32.
Donât forget JPEG XS, which is a very lightweight 2:1 to 6:1 compression that supports YUV bit depths up to 16 bits.
NV12 is the top of my list at the moment as it is needed for H264, but I am building this in a modular manner so it can be used stand alone also as demonstrated above.
3 Likes
will try running a11 again in the weekend. Hereâs what Iâm seeing at the moment:
video showing looking glass host closing
A10 works without a hitch.
looking-glass-client -s
[I] main.c:692 | run | Looking Glass (a69630764b)
[I] main.c:693 | run | Locking Method: Atomic
[I] main.c:686 | try_renderer | Using Renderer: OpenGL
[I] main.c:775 | run | Using: OpenGL
[I] main.c:901 | run | Waiting for host to signal it's ready...
[I] opengl.c:552 | pre_configure | Vendor : X.Org
[I] opengl.c:553 | pre_configure | Renderer: Radeon RX 550 Series (POLARIS12, DRM 3.25.0, 4.17.9-1-hardened, LLVM 6.0.1)
[I] opengl.c:554 | pre_configure | Version : 3.1 Mesa 18.1.4
[I] opengl.c:566 | pre_configure | Using GL_AMD_pinned_memory
[I] main.c:921 | run | Host ready, starting session
[I] main.c:177 | updatePositionInfo | client 1024x768, guest 1680x1050, target 1024x640, scaleX: 1.64, scaleY 1.64
[W] main.c:180 | updatePositionInfo | Window size doesn't match guest resolution, cursor alignment may not be reliable
[I] opengl.c:602 | configure | Using decoder: NULL
[E] opengl.c:536 | _check_gl_error | 682: glBufferData = 1282 (invalid operation)
The last two lines repeat until both the host and guest freezes simultaneously for 10 to 20 seconds then the guest crashes without any BSOD or warning. The host recovers fine.
Iâm using latest Win10 LTSB (as of July 2018) as guest and an up-to-date Arch as host. The gpu passed to the guest is a R9 280x.
I did a sanity check and the âglBufferDataâ function works fine for buffering a triangle vertices in a SDL window context using GLEW for gl functions binding. You are using a target Iâm not familiar with (GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD) so maybe this check is useless.
Youâre using the AUR arenât you? The author of that package didnât do it right and it does not work.
Use the actual tagged releases from GitHub.
@gnif Is there any way you can send a takedown request to the author of that AUR package? It seems to get an unhealthy amount of traction.
1 Like
yeah, weâve had the same problem with vfio-tools.
some rando packaged it in a way that doesnât install python/ddcutil properly and we canât get him to change it
1 Like
Yes I was using the AUR but I have the same behavior using a binary compiled from the A11 release sources archive.
I followed the instructions given in the âQuickstart Guideâ to build it.
The only thing that differ is the first line of output which is now:
[I] main.c:692 | run | Looking Glass ()This is because the release build is not building from a git source tree, a such it canât determine itâs build version. Its a bug, but nothing I am worried about fixing at this point since itâs harmless.
Just managed to get YUV420 support working (NV12 is harder and will need more time). Itâs slow and crappy for the moment as the client is converting back to RGB on the CPU, idealy this should be done in a GL shader.
I think you missed my first post ^^
No, I did not. You have not provided any details as to what you have done, tried or your logs or system configuration. GPU, Resolution of host and guest, etcâŚ