Hi,
On 1/30/24 20:08, Werner Sembach wrote:
> Hi,
>
> Am 30.01.24 um 19:35 schrieb Hans de Goede:
>> Hi,
>>
>> On 1/30/24 19:09, Werner Sembach wrote:
>>> Hi Hans,
>>>
>>> resend because Thunderbird htmlified the mail :/
>> I use thunderbird too. If you right click on the server name
>> and then
Hi,
Am 30.01.24 um 19:35 schrieb Hans de Goede:
Hi,
On 1/30/24 19:09, Werner Sembach wrote:
Hi Hans,
resend because Thunderbird htmlified the mail :/
I use thunderbird too. If you right click on the server name
and then go to "Settings" -> "Composition & Addressing"
and then uncheck
Hi,
On 1/30/24 19:09, Werner Sembach wrote:
> Hi Hans,
>
> resend because Thunderbird htmlified the mail :/
I use thunderbird too. If you right click on the server name
and then go to "Settings" -> "Composition & Addressing"
and then uncheck "Compose messages in HTML format"
I think that should
Hi Hans,
resend because Thunderbird htmlified the mail :/
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
Hi Hans,
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
also between built-in and external devices.
IMHO it
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
> Hi Hans,
>
> Am 29.01.24 um 14:24 schrieb Hans de Goede:
>> That sounds workable OTOH combined with your remarks about also supporting
>> lightbars. I'm starting to think that we need to just punt this to userspace.
>>
>> So basically
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
Am 19.01.24 um 09:44 schrieb Hans de Goede:
So my proposal would be an ioctl interface (ioctl only no r/w)
using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
For per
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
> Am 19.01.24 um 09:44 schrieb Hans de Goede:
>> So my proposal would be an ioctl interface (ioctl only no r/w)
>> using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
>>
>> For per key controllable rgb LEDs we need to discuss a
Hi,
On 1/19/24 21:15, Pavel Machek wrote:
> Hi!
>
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular
entity"
- Con:
Am 19.01.24 um 23:14 schrieb Pavel Machek:
Hi!
And while I would personally hate it, you can imagine a use case where
you'd like a keypress to have a visual effect around the key you
pressed. A kind of force feedback, if you will. I don't actually know,
and correct me if I'm wrong, but feels
Hi!
> > And while I would personally hate it, you can imagine a use case where
> > you'd like a keypress to have a visual effect around the key you
> > pressed. A kind of force feedback, if you will. I don't actually know,
> > and correct me if I'm wrong, but feels like implementing that outside
Hi!
> > > And then storing RGB in separate bytes, so userspace will then
> > > always send a buffer of 192 bytes per line (64x3) x 14 rows
> > > = 3072 bytes. With the kernel driver ignoring parts of
> > > the buffer where there are no actual keys.
> > That's really really weird interface. If you
Hi,
Am 19.01.24 um 21:15 schrieb Pavel Machek:
Hi!
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular entity"
- Con:
- No preexisting UPower
Hi!
> >> 2. Implement per-key keyboards as auxdisplay
> >>
> >> - Pro:
> >>
> >> - Already has a concept for led positions
> >>
> >> - Is conceptually closer to "multiple leds forming a singular
> >> entity"
> >>
> >> - Con:
> >>
> >> - No preexisting UPower
On Fri, Jan 19, 2024 at 12:51:21PM +0200, Jani Nikula wrote:
> On Fri, 19 Jan 2024, Hans de Goede wrote:
> > For per key controllable rgb LEDs we need to discuss a coordinate
> > system. I propose using a fixed size of 16 rows of 64 keys,
> > so 64x16 in standard WxH notation.
> >
> > And then
Hi,
Am 19.01.24 um 11:51 schrieb Jani Nikula:
On Fri, 19 Jan 2024, Hans de Goede wrote:
For per key controllable rgb LEDs we need to discuss a coordinate
system. I propose using a fixed size of 16 rows of 64 keys,
so 64x16 in standard WxH notation.
And then storing RGB in separate bytes, so
Hi,
sorry have to resend, thunderbird html-ified the mail
Am 19.01.24 um 09:44 schrieb Hans de Goede:
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable
Hi,
Am 19.01.24 um 09:44 schrieb Hans de Goede:
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable hidraw here
for a potential userspace driver implementation
On Fri, 19 Jan 2024, Hans de Goede wrote:
> For per key controllable rgb LEDs we need to discuss a coordinate
> system. I propose using a fixed size of 16 rows of 64 keys,
> so 64x16 in standard WxH notation.
>
> And then storing RGB in separate bytes, so userspace will then
> always send a
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
> Hi!
>
>> We have an upcoming device that has a per-key keyboard backlight, but does
>> the control completely via a wmi/acpi interface. So no usable hidraw here
>> for a potential userspace driver implementation ...
>>
>> So a quick summary for the
Hi
Am 18.01.24 um 18:45 schrieb Pavel Machek:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable hidraw here
for a potential userspace driver implementation ...
So a quick summary for the ideas floating
Hi!
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here
> for a potential userspace driver implementation ...
>
> So a quick summary for the ideas floating in this thread so far:
>
> 1. Expand
Hi Werner,
Once again, sorry for the very slow response here.
On 11/27/23 11:59, Werner Sembach wrote:
> Hi Hans,
>
> Am 22.11.23 um 19:34 schrieb Hans de Goede:
>> Hi Werner,
> [snip]
> Another idea I want to throw in the mix:
>
> Maybe the kernel is not the right place to
Hi Hans & the others,
[snip]
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does the
control completely via a wmi/acpi interface. So no usable hidraw here for a
potential userspace driver implementation ...
So a quick summary for
Hi Hans,
Am 22.11.23 um 19:34 schrieb Hans de Goede:
Hi Werner,
[snip]
Another idea I want to throw in the mix:
Maybe the kernel is not the right place to implement this at all. RGB stuff is
not at all standardized and every vendor is doing completely different
interfaces, which does not
Hi Werner,
On 11/21/23 14:29, Werner Sembach wrote:
>
> Am 21.11.23 um 13:20 schrieb Hans de Goede:
>> Hi Werner,
>>
>> On 11/21/23 12:33, Werner Sembach wrote:
>>> Hi,
>>>
>>> Am 20.11.23 um 21:52 schrieb Pavel Machek:
Hi!
>>> So... a bit of rationale. The keyboard does not really
Am 21.11.23 um 13:20 schrieb Hans de Goede:
Hi Werner,
On 11/21/23 12:33, Werner Sembach wrote:
Hi,
Am 20.11.23 um 21:52 schrieb Pavel Machek:
Hi!
So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led") and not
a
Hi Werner,
On 11/21/23 12:33, Werner Sembach wrote:
> Hi,
>
> Am 20.11.23 um 21:52 schrieb Pavel Machek:
>> Hi!
>>
> So... a bit of rationale. The keyboard does not really fit into the
> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> a matrix of them.
Hi,
Am 20.11.23 um 21:52 schrieb Pavel Machek:
Hi!
So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led") and not
a matrix of them.
Makes sense.
We do see various strange displays these days -- they commonly have
On Mon 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula
> wrote:
> >
> > One could also reasonably make the argument that controlling the
> > individual keyboard key backlights should be part of the input
> > subsystem. It's not a display per se. (Unless you
Hi!
> >> So... a bit of rationale. The keyboard does not really fit into the
> >> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> >> a matrix of them.
> >
> > Makes sense.
> >
> >> We do see various strange displays these days -- they commonly have
> >> rounded corners
On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula wrote:
>
> One could also reasonably make the argument that controlling the
> individual keyboard key backlights should be part of the input
> subsystem. It's not a display per se. (Unless you actually have small
> displays on the keycaps, and I think
On Mon, 16 Oct 2023, Miguel Ojeda wrote:
> On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek wrote:
>>
>> So... a bit of rationale. The keyboard does not really fit into the
>> LED subsystem; LEDs are expected to be independent ("hdd led") and not
>> a matrix of them.
>
> Makes sense.
>
>> We do see
On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek wrote:
>
> So... a bit of rationale. The keyboard does not really fit into the
> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> a matrix of them.
Makes sense.
> We do see various strange displays these days -- they commonly
Hi!
> coming from the leds mailing list I'm writing with Pavel how to best handle
> per-key RGB keyboards.
>
> His suggestion was that it could be implemented as an aux display, but he
> also suggested that I ask first if this fits.
Thanks for doing this.
> The specific keyboard RGB controller
Hi!
> > The specific keyboard RGB controller I want to implement takes 6*21 rgb
> > values. However not every one is actually mapped to a physical key. e.g. the
> > bottom row needs less entries because of the space bar. Additionally the
> > keys are ofc not in a straight line from top to bottom.
Hi,
coming from the leds mailing list I'm writing with Pavel how to best handle
per-key RGB keyboards.
His suggestion was that it could be implemented as an aux display, but he also
suggested that I ask first if this fits.
The specific keyboard RGB controller I want to implement takes 6*21
37 matches
Mail list logo
