Re: [PATCH 0/1] platform/x86: dell-wmi: Uncomment events that were
On Mon, Mar 18, 2019 at 01:00:32PM +0100, Pali Rohár wrote: > > = > > > > > > Left WMI key: Windows Mobility Center > > Press:'x' > > Hold: - > > Release: - > > > > In my machine (Inspiron 5420), whenever I press this key, the key > > outputs the character "x". I've seen nothing on dmesg even if I > > keep this key pressed for longer amounts of time. I'm still trying > > to understand why this is hapenning. > > This is strange. Is not also some Alt/Meta/Ctrl or other modifier sent > too? Because Meta+X could be some windows shortcut... > > > > > > > Middle WMI key: Dell Audio With Preset Switch > > Press:Key with type 0x and code 0xe02a pressed > > Hold: - > > Release: Key with type 0x and code 0xe02b pressed > > > > Differently from what you saw on a Inspiron 7520, I could not > > reproduce the behavior that you reported on the first link above. > > In my case, when I press the key, the code 0xe02a is shown at dmesg > > only once. Also, even though I keep it pressed for longer than ~30 > > seconds or so, I could not see the entry 0xe02c apper. More on that > > behavior later on. When releasing the key, I can see the code 0xe02b > > show up at dmesg. > > > > > > Right WMI key: Dell Instant Launch > > Press:- > > Hold: - > > Release: - > > > > This key is with a really weird behavior on my machine. > > When testing, I would normally press and relase so that the following > > messages would pop-up: > > > > [ 2830.499420] atkbd serio0: Unknown key pressed (translated set 2, > > code 0x60 on isa0060/serio0). > > [ 2830.499422] atkbd serio0: Use 'setkeycodes 60 ' > > to make it known. > > This means that you have not configured atkbd keycodes yet. Run > setkeycodecs and assign some keycode for that scancode 60. After that > kernel atkbd (PS/2 keyboard) starts sending events to userspace. All right, I'll investigate and try these approaches, thanks! > > There are two ways how Dell firmware can inform operating system that > key was pressed. Notebook keyboard is connected to motherboard via > classic PS/2 port (of PS/2 port is emulated for OS). So operating system > sees PS/2 keyboard and key pressed are received by PS/2 atkbd driver. > For some (unknown/strange?) reasons firmware send some keys not via PS/2 > keyboard port, but via ACPI interface, hence needs for dell_wmi driver > which handle them. > > So some keypress events come via PS/2, some via ACPI-WMI. Linux kernel > then send all keypress events to userspace. > > When debugging problems with hot keys, you always need to look at all > possible sources... > > > dell-wmi.c is a driver for receiving APCI-WMI events; atkbd.c is a PS/2 > keyboard driver. > > In dell-wmi.c is a function dell_wmi_events_set_enabled which is needed > to call on some Dell machines to start receiving those ACPI-WMI events. > You can try to call it for your laptop, maybe it is needed too. > Currently it is called only for two laptop models, see table > dell_wmi_smbios_list. > > > In the meantime, I'll try to find out why the first button is outputting > > an "x" character on my machine. > > Check that you caught all keypresses. X11 tools just print keys known to > X server, not all which are supported by Linux kernel. > > You can use e.g. input-events utility. And also check all input devices, > as wrote some keys are send via PS/2 keyboard input device, some via > ACPI-WMI input device. > Ok, I was unaware of this, I'll keep this in mind when reasearching. I think that now I'm going to take my time in order to process all that you explained to me and study this issue a little more, then possibly start a new thread regarding my findings. Thanks for your attention and time, Renato
Re: [PATCH 0/1] platform/x86: dell-wmi: Uncomment events that were
Hello, On Sat, Mar 16, 2019 at 10:17:56AM +0100, Pali Rohár wrote: > > Looks like that those keys are not as obvious as you wrote. Look at my > email with some investigation about Dell Audio With Preset Switch key: > https://www.spinics.net/lists/platform-driver-x86/msg15593.html > > Also there is another user who wrote about 0xe02c key generated by > Inspirion 7520: https://ubuntuforum-br.org/index.php?topic=105434.0 > > You can a testing machine 5420, can you prove that behavior described in > my previous email match also your machine? > Thanks for the feedback, I was unaware of this issue. I've performed some tests in my machine and this is what I've found so far: = Left WMI key: Windows Mobility Center Press:'x' Hold: - Release: - In my machine (Inspiron 5420), whenever I press this key, the key outputs the character "x". I've seen nothing on dmesg even if I keep this key pressed for longer amounts of time. I'm still trying to understand why this is hapenning. Middle WMI key: Dell Audio With Preset Switch Press:Key with type 0x and code 0xe02a pressed Hold: - Release: Key with type 0x and code 0xe02b pressed Differently from what you saw on a Inspiron 7520, I could not reproduce the behavior that you reported on the first link above. In my case, when I press the key, the code 0xe02a is shown at dmesg only once. Also, even though I keep it pressed for longer than ~30 seconds or so, I could not see the entry 0xe02c apper. More on that behavior later on. When releasing the key, I can see the code 0xe02b show up at dmesg. Right WMI key: Dell Instant Launch Press:- Hold: - Release: - This key is with a really weird behavior on my machine. When testing, I would normally press and relase so that the following messages would pop-up: [ 2830.499420] atkbd serio0: Unknown key pressed (translated set 2, code 0x60 on isa0060/serio0). [ 2830.499422] atkbd serio0: Use 'setkeycodes 60 ' to make it known. But what I realized was that, if I kept this button pressed for about ~3 seconds or so (like when your experiment in the link above), dmesg would not ouput anything untill those ~3 seconds elapsed. When they did, then dmesg log would have the following entries: [ 3058.494003] atkbd serio0: Unknown key pressed (translated set 2, code 0x60 on isa0060/serio0). [ 3058.494008] atkbd serio0: Use 'setkeycodes 60 ' to make it known. [ 3058.501494] dell_wmi: Unknown key with type 0x and code 0xe028 pressed The last message being the weirdest, It would seem that only after about 3 seconds or so, the driver is being notified of it. = Anyway, It's clear now that this patch trully makes no sense since the hardwares (Inspiron 7520 x Inspiron 5420) are behaving somewhat differently on these keys. Either way, It seems that at both of them, there are three behaviors that are strange. I'm still trying to learn kernel development (I'm a newbie) so could you please point out whether this is worth it to investigate, or if should I leave this as is? In the meantime, I'll try to find out why the first button is outputting an "x" character on my machine. Thanks! Renato
[Patch v2] staging fbtft: Fixed lines exceeding columns limit
Fix checkpatch.pl warnings of lines exceeding 80 columns.
Break lines in order to reduce instructions lengths to less than 80 columns.
Signed-off-by: Renato Soma <renatoy...@gmail.com>
---
Changes in v2:
- Break lines respecting function parameters alignment.
drivers/staging/fbtft/fbtft-bus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index a263bce2..871b307 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -22,10 +22,13 @@ void func(struct fbtft_par *par, int len, ...)
\
if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {\
va_start(args, len); \
for (i = 0; i < len; i++) { \
- buf[i] = modifier((data_type)va_arg(args, unsigned
int)); \
+ buf[i] = modifier((data_type)va_arg(args, \
+ unsigned int)); \
} \
va_end(args); \
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device,
buffer_type, buf, len, "%s: ", __func__); \
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
+ par->info->device, buffer_type, buf, len, \
+ "%s: ", __func__); \
} \
\
va_start(args, len); \
@@ -37,7 +40,8 @@ void func(struct fbtft_par *par, int len, ...)
\
} \
\
*buf = modifier((data_type)va_arg(args, unsigned int)); \
- ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0);
\
+ ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
+0); \
if (ret < 0) \
goto out; \
len--;\
@@ -48,7 +52,8 @@ void func(struct fbtft_par *par, int len, ...)
\
if (len) {\
i = len; \
while (i--) \
- *buf++ = modifier((data_type)va_arg(args, unsigned
int)); \
+ *buf++ = modifier((data_type)va_arg(args, \
+ unsigned int)); \
fbtft_write_buf_dc(par, par->buf, \
len * (sizeof(data_type) + offset), 1);\
} \
--
2.7.4
[Patch v2] staging fbtft: Fixed lines exceeding columns limit
Fix checkpatch.pl warnings of lines exceeding 80 columns.
Break lines in order to reduce instructions lengths to less than 80 columns.
Signed-off-by: Renato Soma
---
Changes in v2:
- Break lines respecting function parameters alignment.
drivers/staging/fbtft/fbtft-bus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index a263bce2..871b307 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -22,10 +22,13 @@ void func(struct fbtft_par *par, int len, ...)
\
if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {\
va_start(args, len); \
for (i = 0; i < len; i++) { \
- buf[i] = modifier((data_type)va_arg(args, unsigned
int)); \
+ buf[i] = modifier((data_type)va_arg(args, \
+ unsigned int)); \
} \
va_end(args); \
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device,
buffer_type, buf, len, "%s: ", __func__); \
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
+ par->info->device, buffer_type, buf, len, \
+ "%s: ", __func__); \
} \
\
va_start(args, len); \
@@ -37,7 +40,8 @@ void func(struct fbtft_par *par, int len, ...)
\
} \
\
*buf = modifier((data_type)va_arg(args, unsigned int)); \
- ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0);
\
+ ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
+0); \
if (ret < 0) \
goto out; \
len--;\
@@ -48,7 +52,8 @@ void func(struct fbtft_par *par, int len, ...)
\
if (len) {\
i = len; \
while (i--) \
- *buf++ = modifier((data_type)va_arg(args, unsigned
int)); \
+ *buf++ = modifier((data_type)va_arg(args, \
+ unsigned int)); \
fbtft_write_buf_dc(par, par->buf, \
len * (sizeof(data_type) + offset), 1);\
} \
--
2.7.4
Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit
On Fri, Apr 13, 2018 at 03:57:47PM +0300, Dan Carpenter wrote: > > - ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); > > \ > > I feel like the original is basically OK but if we're going to change it > then align it like this: > > ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, > \ >0); > \ > > > Etc. > Alright, I'll fix this issue then send another email with the fixed patch. Thanks! renato
Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit
On Fri, Apr 13, 2018 at 03:57:47PM +0300, Dan Carpenter wrote: > > - ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); > > \ > > I feel like the original is basically OK but if we're going to change it > then align it like this: > > ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, > \ >0); > \ > > > Etc. > Alright, I'll fix this issue then send another email with the fixed patch. Thanks! renato
[PATCH] staging fbtft: Fixed lines exceeding columns limit
Fix checkpatch.pl warnings of line sizes exceeding 80 columns.
Break lines in order to reduce the instructions lengths to less than 80 columns.
Signed-off-by: Renato Soma <renatoy...@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index a263bce2..57742d7 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -22,10 +22,13 @@ void func(struct fbtft_par *par, int len, ...)
\
if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {\
va_start(args, len); \
for (i = 0; i < len; i++) { \
- buf[i] = modifier((data_type)va_arg(args, unsigned
int)); \
+ buf[i] = modifier((data_type)va_arg(args, \
+ unsigned int)); \
} \
va_end(args); \
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device,
buffer_type, buf, len, "%s: ", __func__); \
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
+ par->info->device, buffer_type, \
+ buf, len, "%s: ", __func__); \
} \
\
va_start(args, len); \
@@ -37,7 +40,8 @@ void func(struct fbtft_par *par, int len, ...)
\
} \
\
*buf = modifier((data_type)va_arg(args, unsigned int)); \
- ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0);
\
+ ret = fbtft_write_buf_dc(par, par->buf, \
+ sizeof(data_type) + offset, 0); \
if (ret < 0) \
goto out; \
len--;\
@@ -48,7 +52,8 @@ void func(struct fbtft_par *par, int len, ...)
\
if (len) {\
i = len; \
while (i--) \
- *buf++ = modifier((data_type)va_arg(args, unsigned
int)); \
+ *buf++ = modifier((data_type)va_arg(args, \
+ unsigned int)); \
fbtft_write_buf_dc(par, par->buf, \
len * (sizeof(data_type) + offset), 1);\
} \
--
2.7.4
[PATCH] staging fbtft: Fixed lines exceeding columns limit
Fix checkpatch.pl warnings of line sizes exceeding 80 columns.
Break lines in order to reduce the instructions lengths to less than 80 columns.
Signed-off-by: Renato Soma
---
drivers/staging/fbtft/fbtft-bus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index a263bce2..57742d7 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -22,10 +22,13 @@ void func(struct fbtft_par *par, int len, ...)
\
if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {\
va_start(args, len); \
for (i = 0; i < len; i++) { \
- buf[i] = modifier((data_type)va_arg(args, unsigned
int)); \
+ buf[i] = modifier((data_type)va_arg(args, \
+ unsigned int)); \
} \
va_end(args); \
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device,
buffer_type, buf, len, "%s: ", __func__); \
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
+ par->info->device, buffer_type, \
+ buf, len, "%s: ", __func__); \
} \
\
va_start(args, len); \
@@ -37,7 +40,8 @@ void func(struct fbtft_par *par, int len, ...)
\
} \
\
*buf = modifier((data_type)va_arg(args, unsigned int)); \
- ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0);
\
+ ret = fbtft_write_buf_dc(par, par->buf, \
+ sizeof(data_type) + offset, 0); \
if (ret < 0) \
goto out; \
len--;\
@@ -48,7 +52,8 @@ void func(struct fbtft_par *par, int len, ...)
\
if (len) {\
i = len; \
while (i--) \
- *buf++ = modifier((data_type)va_arg(args, unsigned
int)); \
+ *buf++ = modifier((data_type)va_arg(args, \
+ unsigned int)); \
fbtft_write_buf_dc(par, par->buf, \
len * (sizeof(data_type) + offset), 1);\
} \
--
2.7.4
