lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 06 Aug 2022 21:32:43 +1200
From:   Luke Jones <luke@...nes.dev>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] asus-wmi: Add support for RGB keyboards

Hi,

On Sat, Aug 6 2022 at 11:10:37 +0200, Andy Shevchenko 
<andy.shevchenko@...il.com> wrote:
> On Fri, Aug 5, 2022 at 10:20 AM Luke D. Jones <luke@...nes.dev> wrote:
>> 
>>  This is a patch series to add RGB support for ASUS laptops.
>>  The laptops with this RGB tend to be the TUF series of gamer 
>> laptops.
>> 
>>  The first step is initial bringup of support using the multicolor 
>> LED API.
>> 
>>  These types of keyboards implement a slightly more complex 
>> interface than
>>  just RGB control however - they also have modes with can be static 
>> LED,
>>  blinking, rainbow, color cycles, and more. They also have some 
>> custom
>>  animations that can play depending on device state, such as 
>> suspended
>>  playing a fancy colour cycle, or playing a "wave" animation.
>> 
>>  Two of the patches add support for these features.
>> 
>>  The last patch adds documentation in:
>>  Documentation/ABI/testing/sysfs-platform-asus-wmi
>> 
>>  Some notes:
>> 
>>  - this patch series obsoletes the previous RGB patches by myself
>> 
>>  - it is not possible to add attribute groups to multicolor LED as
>>    they get overwritten by `led_multicolor_groups` in
>>    `led_classdev_multicolor_register_ext`.
>> 
>>  - the methods for RGB control do not provide a way to fetch 
>> exisiting
>>    state, so these methods are WO.
>> 
>>  - There is an existing `asus::kbd_backlight`, this provides a 4-step
>>    brightness to the RGB (off,low,med,high) individually to 
>> multicolor.
>>    I was unsure of the effect of adding a similar path so have used 
>> the
>>    `asus::multicolour::kbd_backlight` name to be clear about purpose.
>>    If the `asus::kbd_backlight` is off, then no RGB is shown at all.\
>> 
>>  I'm hopeful that this patch series addresses all previous feedback 
>> related
>>  to the obsoleted patches.
> 
> There are so many patches

This is what Hans requested that I do after the previous submissions,

>  and versioning of all of this is completely
> broken.

I was unsure how to handle this as the previous patches were 
individual, I thought perhaps this patch series is a good place to 
restart since the work done is a bit different.

I will try to better track what I do in future.

> You really have to clean up the mess and realize what version
> of this is. To me it looks like this series is v5 or so of the
> previously sent patch(es). Also you missed the changelog between
> versions so we can see what you have done from vX to vX+1 for the
> whole range (1 ... X+1).

As described before I thought this would hopefully be a good point at 
which to reset due to the changes requested by Hans which meant that 
the underlying structure is different.

I do have another version already prepped, so I will do my best to 
address the previous submissions and your concerns in the cover letter 
along with a changelog.

> 
> --
> With Best Regards,
> Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ