interface.
Thanks,
Armin Wolf
The folder structure and naming scheme with nb04 is im preparation for
other parts of tuxedo-drivers to be upstreamed. NB04 is one of the
board_vendor dmi strings on TUXEDO devices that aligns with which part of
tuxedo-drivers implements the features of that device
ery
useful for the wmi-bmof driver :).
Thanks,
Armin Wolf
This has drawbacks:
* It is not documented.
* A single attribute can be instantiated multiple times, overwriting the
shared size field.
* It prevents the structure to be moved to read-only memory.
Introduce a new dedicated callback
Pavel
Using an ID-based interface would allow for more flexibility and allow
us to support 3D-arrays.
Thanks,
Armin Wolf
imilar the the HID LampArray interface except that:
- we can read the current color
- we can omit optional information
- we can extend the interface later (animations, etc)
Thanks,
Armin Wolf
is properly documented so that
they can implement
support for it under Windows.
I would even volunteer to write the necessary OpenRGB backend since i already
contributed to
the project in the past.
Thanks,
Armin Wolf
as a "one value per file" rule, i suggest that we use a chardev
interface
for querying per-LED data and for setting/getting LED colors.
I do not know if mixing sysfs (for controller attributes like number of LEDs,
etc) and IOCTL
(for setting/getting LED colors) is a good idea, any thoughts?
Thanks,
Armin Wolf
llumination subsystem instead, but i have to agree that we should be
doing this
only after enough drivers are inside the kernel, so we can design a suitable
interface for them. For now, creating a virtual HID interface seems to be good
enough.
Thanks,
Armin Wolf
Also at Armin and Hans: Do you
Am 02.10.24 um 10:42 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Armin,
Am 01.10.24 um 18:45 schrieb Armin Wolf:
[...snipped...]
Why not having a simple led driver for HID LampArray devices which exposes the
whole LampArray as a single LED?
Yes that is my plan, but
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it onl
ge of LEDs
- ioctl for updating multiple LEDs at once
If we implement this as a separate subsystem ("illumination subsystem"), then
different
drivers could use this. This would also allow us to add additional ioctl calls
later
for more features.
Thanks,
Armin Wolf
+
+// We don'
Am 27.09.24 um 08:59 schrieb Werner Sembach:
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a
per-key
controllable RGB keyboard backlight. The firmware API for it is
implemented
via
Am 27.09.24 um 13:24 schrieb Werner Sembach:
Hi,
an additional question below
Am 27.09.24 um 08:59 schrieb Werner Sembach:
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
[...]
+// We don't know if the WMI API is stable and how unique the GU
Am 26.09.24 um 19:44 schrieb Werner Sembach:
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
To make the backlight userspace configurable this driver emulates a
LampArray HID device a
Am 23.05.24 um 18:29 schrieb Greg KH:
On Thu, May 23, 2024 at 05:59:39PM +0200, Armin Wolf wrote:
Am 23.05.24 um 15:13 schrieb Barry Kauler:
On Wed, May 22, 2024 at 12:58 AM Armin Wolf wrote:
Am 20.05.24 um 18:22 schrieb Alex Deucher:
On Sat, May 18, 2024 at 8:17 PM Armin Wolf wrote
know about it.
From w_ar...@gmx.de Wed Jun 12 14:43:21 2024
From: Armin Wolf
Date: Thu, 23 May 2024 19:30:31 +0200
Subject: Revert "drm/amdgpu: init iommu after amdkfd device init"
To: alexander.deuc...@amd.com, christian.koe...@amd.com, xinhui@amd.com,
gre...@linuxfoundation.org,
Am 04.06.24 um 20:28 schrieb Deucher, Alexander:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Kuehling, Felix
Sent: Tuesday, June 4, 2024 2:25 PM
To: Armin Wolf ; Deucher, Alexander
; Koenig, Christian
; Pan, Xinhui ;
gre...@linuxfoundation.org
Am 23.05.24 um 19:30 schrieb Armin Wolf:
This reverts commit 56b522f4668167096a50c39446d6263c96219f5f.
A user reported that this commit breaks the integrated gpu of his
notebook, causing a black screen. He was able to bisect the problematic
commit and verified that by reverting it the notebook
6.8.1 also works on his device, so the
upstream commit itself seems to be ok.
An amdgpu developer (Alex Deucher) confirmed that this patch should
have never been ported to 5.15 in the first place, so revert this
commit from the 5.15 stable series.
Reported-by: Barry Kauler
Signed-off-by: Armin
Am 23.05.24 um 15:13 schrieb Barry Kauler:
On Wed, May 22, 2024 at 12:58 AM Armin Wolf wrote:
Am 20.05.24 um 18:22 schrieb Alex Deucher:
On Sat, May 18, 2024 at 8:17 PM Armin Wolf wrote:
Am 17.05.24 um 03:30 schrieb Barry Kauler:
Armin, Yifan, Prike,
I will top-post, so you don't
Am 20.05.24 um 18:22 schrieb Alex Deucher:
On Sat, May 18, 2024 at 8:17 PM Armin Wolf wrote:
Am 17.05.24 um 03:30 schrieb Barry Kauler:
Armin, Yifan, Prike,
I will top-post, so you don't have to scroll down.
After identifying the commit that causes black screen with my gpu, I
poste
developers hear from this issue.
Thanks you for you persistence in finding the offending commit.
Armin Wolf
On Thu, May 9, 2024 at 4:08 PM Barry Kauler wrote:
On Fri, May 3, 2024 at 9:03 PM Armin Wolf wrote:
...
# lspci | grep VGA
05:00.0 VGA compatible controller: Advanced Micro Devices
ddat_gt->hwmon_dev = hwmon_dev;
}
@@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
W
+0x70/0xc0
[] bus_add_driver+0x112/0x210
[] driver_register+0x55/0x100
[] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it.
Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
Signed-off-by: Armin Wolf
---
drivers/gpu/drm/a
m userspace (like Windows
can do). Maybe with an allow list per GUID to only allow
specific calls, so that we can avoid possible dangerous calls.
Armin Wolf recently became the WMI bus maintainer.
Armin, we are discussing how to deal with (laptop) keyboards
which have a separate RGB LED per key an
24 matches
Mail list logo
