[PATCH v2] media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K

rates (29.970 and 59.940 fps). Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Drung --- In version 2, I only enhanced the comment in the code to document that the quirk is only applied to broken responses (guarded by ctrl->bmHint > 255). So in case Elgato fixes the firmware, the quirk will be skipped.

[PATCH] media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K

ato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67. Therefore add a quirk to correct the malformed data structure. The quirk was successfully tested with VLC, OBS, and Chromium using different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160, 1920x1080), and frame rates (29.970 a

Re: PROBLEM: Broken pixel format for Elgato Cam Link 4K

Am Freitag, den 20.11.2020, 16:45 -0500 schrieb Adam Goode: > On Fri, Nov 20, 2020 at 1:52 PM Benjamin Drung > wrote: > > > > Hi, > > > > I own an Elgato Cam Link 4K which is a very popular USB HDMI > > capture > > device (number one capture car

PROBLEM: Broken pixel format for Elgato Cam Link 4K

1.598559] usb 2-3: Product: Cam Link 4K [1.598560] usb 2-3: Manufacturer: Elgato ``` I have another problems with 5.9.8-050908.202011101634 and 5.10.0- 051000rc4.202011152030: Chromium fail to access the video device of Cam Link 4K and the notebook integrated webcam has a too low brightness.

[PATCH] ARM: dts: exynos: Fix spelling mistake of EXYNOS5420

The SoC name EXYNOS5420 was misspelled. Signed-off-by: Benjamin Drung --- arch/arm/boot/dts/exynos5420.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index aaff15880761..5fb2326875dc 100644 --- a

Re: Read-protected UEFI variables

Am Mittwoch, den 14.02.2018, 19:18 +0100 schrieb Môshe van der Sterre: > On 02/14/2018 02:21 PM, Benjamin Drung wrote: > > If the UEFI is as secure as storing an unencrypted file on a hard > > drive, I am satisfied. Or do you have a better idea where to store > > the > &

Re: Read-protected UEFI variables

Am Mittwoch, den 14.02.2018, 13:09 + schrieb Ard Biesheuvel: > On 14 February 2018 at 12:52, Benjamin Drung > wrote: > > Hi, > > > > I am exploring the possibility to store SSH and other keys in UEFI > > variables for systems that do not have persistent stora

Read-protected UEFI variables

. 2) Instead of hard-coding GUIDs, add a kernel module parameter to specify the GUIDs. Maybe have a default list in the kernel module. 3) Add a mount option to specify the protected GUIDs. Feedback is welcome. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks