* Re: [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
From: Geert Uytterhoeven @ 2018-11-03 22:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Kosina, benjamin.tissoires, Hans de Goede, Colin King,
peter.hutterer, mustafakuscu, Daniel Drake, linux-input,
Linux Kernel Mailing List
In-Reply-To: <20181102151443.758229-1-arnd@arndb.de>
On Fri, Nov 2, 2018 at 4:16 PM Arnd Bergmann <arnd@arndb.de> wrote:
> asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
> is disabled, or not reachable from a built-in device driver. This leads to
> a theoretical evaluation of an uninitialized variable that the compiler
> complains about, failing to check that the hardcoded return value makes
> this an unreachable code path:
>
> In file included from include/linux/printk.h:336,
> from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from include/linux/dmi.h:5,
> from drivers/hid/hid-asus.c:29:
> drivers/hid/hid-asus.c: In function 'asus_input_configured':
> include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> __dynamic_dev_dbg(&descriptor, dev, fmt, \
> ^~~~~~~~~~~~~~~~~
> drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
> u32 value;
> ^~~~~
>
> With an extra IS_ENABLED() check, the warning goes away.
>
> Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven by WMI")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 6/8] Input: olpc_apsp: check FIFO status on open(), not probe()
From: Pavel Machek @ 2018-11-02 22:16 UTC (permalink / raw)
To: Lubomir Rintel
Cc: linux-kernel, linux-clk, devicetree, linux-input, Rob Herring,
Mark Rutland, Dmitry Torokhov, Michael Turquette, Stephen Boyd
In-Reply-To: <20180910112654.42061-7-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Mon 2018-09-10 13:26:52, Lubomir Rintel wrote:
> Let's defer the FIFO status checking until open().
>
> When we'll get a clk handle, this will allow us to defer clock enablement
> until the device is actually used.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Fix display off hotkey on Asus machines
From: Andy Shevchenko @ 2018-11-02 19:35 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
Platform Driver, Bastien Nocera, Dmitry Torokhov, linux-input,
Linux Kernel Mailing List, linux, João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
On Thu, Nov 1, 2018 at 2:21 AM João Paulo Rechi Vita <jprvita@gmail.com> wrote:
>
> Asus laptops have a hotkey function on the F7 key to turn the display
> backlight OFF, labeled with a screen with a X inside, as shown on
> https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
>
> This hotkey worked on very few Asus models, where the EC acts on the
> backlight and input events are generated only to notify userspace of the
> backlight status. On these machines the first hotkey press turns the
> display backlight OFF and notifies the OS with 0x34, which asus-nb-wmi
> forwards to userspace as KEY_DISPLAY_OFF, and a second press turns it
> back ON and notifies the OS with 0x33, which asus-nb-wmi forwards to
> userspace as KEY_DISPLAYTOGGLE. No other keys turn the display backlight
> back ON, but their input is forwarded normally to the application under
> focus.
>
> But for the majority of models, the EC actually does not act on the
> backlight and we simply get a 0x33 notification every time the key is
> pressed, or alternating values of 0x33 / 0x34. We have confirmed this
> behavior on the following models: E203NAS, GL553VE, X441NC, X441UVK,
> X541UVK, X555DG, X555UB, X555UQ, X560UD, X570ZD and X705FD, and the DSDT
> on these machines and the working one (only confirmed on N552VW) is the
> same for the query involved here.
>
> After trying to get information from Asus for quite some time on how
> this works on Windows, we finally recently got a contact that was able
> to give us a definitive answer and a specification for this feature.
> According this contact the 0x33 / 0x34 is an old behavior and all newer
> machines should only be notifying the OS with 0x35 instead, as newer ECs
> don't control the backlight anymore. When a 0x35 notification is
> received the OS should act on the display backlight. From the spec
> (machine-translated from Chinese):
>
> 1.4 Fn+F7
> Function introduction
>
> After the user presses Fn + F7, the screen will be closed through the
> Windows API. The user will immediately open the screen with the mouse
> and keyboard.
> The API used can be found in the Sample URL:
> https://code.msdn.microsoft.com/windowsdesktop/Coalescable-Timer-Sample-d9da954c
> BIOS implementation
> Increase Notify code
> LCD On: 0x33 (display OSD)
> LCD Off: 0x34 (display OSD)
> LCD Switch: 0x35 (using API switch)
>
> The behavior on Windows with the ATKACPI driver from Asus installed
> matches what is described above, with the hotkey turning OFF the
> backlight of all connected displays with a fading effect, and any cursor
> input or key press turning the backlight back ON. The key press or
> cursor input is passed through to the application under focus or under
> the cursor.
>
> With this information from the spec, a simple analysis of the DSDT
> (pasted on the first commit of this series) shows that in order to have
> the firmware notify the OS with 0x35 and have the OS act on the
> backlight, we need to call WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2)
> on the _WDG device. Then we can simply map that scan code to the
> appropriate key code in the driver.
>
> In include/uapi/linux/input-event-codes.h KEY_DISPLAY_OFF is defined as
> "display device to off state", but it is not actually handled by
> userspace on a GNOME+Xorg stack. There are also KEY_SCREENSAVER and
> KEY_SCREENLOCK / KEY_COFFEE. The former seems to be ignored by userspace
> as well (and its value is higher than 255 so it can't be handled by Xorg
> IIUC), and the later is mapped to XF86ScreenSaver by Xorg and triggers
> the lock screen action on GNOME. KEY_SCREENLOCK seems to be what closest
> matches the behavior described above in a Xorg world. I am not sure if
> any of this changes with Wayland, so any clarifications in that regard
> would be greatly appreciated.
>
Pushed to my review and testing queue, thanks!
> João Paulo Rechi Vita (3):
> asus-wmi: Tell the EC the OS will handle the display off hotkey
> asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
> asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
>
> drivers/platform/x86/asus-nb-wmi.c | 3 +--
> drivers/platform/x86/asus-wmi.c | 3 ++-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.19.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
From: Arnd Bergmann @ 2018-11-02 15:14 UTC (permalink / raw)
To: Jiri Kosina
Cc: Arnd Bergmann, Benjamin Tissoires, Hans de Goede, Colin Ian King,
Peter Hutterer, Mustafa Kuscu, Daniel Drake, linux-input,
linux-kernel
asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
is disabled, or not reachable from a built-in device driver. This leads to
a theoretical evaluation of an uninitialized variable that the compiler
complains about, failing to check that the hardcoded return value makes
this an unreachable code path:
In file included from include/linux/printk.h:336,
from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/dmi.h:5,
from drivers/hid/hid-asus.c:29:
drivers/hid/hid-asus.c: In function 'asus_input_configured':
include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~~~~~~~~~~~~~~~
drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
u32 value;
^~~~~
With an extra IS_ENABLED() check, the warning goes away.
Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven by WMI")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hid/hid-asus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index dc6d6477e961..a1fa2fc8c9b5 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -359,6 +359,9 @@ static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
u32 value;
int ret;
+ if (!IS_ENABLED(CONFIG_ASUS_WMI))
+ return false;
+
ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS2,
ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
--
2.18.0
^ permalink raw reply related
* [PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event
From: liujian @ 2018-11-02 13:48 UTC (permalink / raw)
To: dmitry.torokhov, linux-input; +Cc: linux-kernel, liujian56
syzkaller triggered a UBCAN warning:
[ 196.188950] UBSAN: Undefined behaviour in drivers/input/input.c:62:23
[ 196.188958] signed integer overflow:
[ 196.188964] -2147483647 - 104 cannot be represented in type 'int [2]'
[ 196.188973] CPU: 7 PID: 4763 Comm: syz-executor Not tainted
4.19.0-514.55.6.9.x86_64+ #7
[ 196.188977] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 196.188979] Call Trace:
[ 196.189001] dump_stack+0x91/0xeb
[ 196.189014] ubsan_epilogue+0x9/0x7c
[ 196.189020] handle_overflow+0x1d7/0x22c
[ 196.189028] ? __ubsan_handle_negate_overflow+0x18f/0x18f
[ 196.189038] ? __mutex_lock+0x213/0x13f0
[ 196.189053] ? drop_futex_key_refs+0xa0/0xa0
[ 196.189070] ? __might_fault+0xef/0x1b0
[ 196.189096] input_handle_event+0xe1b/0x1290
[ 196.189108] input_inject_event+0x1d7/0x27e
[ 196.189119] evdev_write+0x2cf/0x3f0
[ 196.189129] ? evdev_pass_values+0xd40/0xd40
[ 196.189157] ? mark_held_locks+0x160/0x160
[ 196.189171] ? __vfs_write+0xe0/0x6c0
[ 196.189175] ? evdev_pass_values+0xd40/0xd40
[ 196.189179] __vfs_write+0xe0/0x6c0
[ 196.189186] ? kernel_read+0x130/0x130
[ 196.189204] ? _cond_resched+0x15/0x30
[ 196.189214] ? __inode_security_revalidate+0xb8/0xe0
[ 196.189222] ? selinux_file_permission+0x354/0x430
[ 196.189233] vfs_write+0x160/0x440
[ 196.189242] ksys_write+0xc1/0x190
[ 196.189248] ? __ia32_sys_read+0xb0/0xb0
[ 196.189259] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 196.189267] ? do_syscall_64+0x22/0x4a0
[ 196.189276] do_syscall_64+0xa5/0x4a0
[ 196.189287] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 196.189293] RIP: 0033:0x44e7c9
[ 196.189299] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00
the syzkaller reproduce script(but can't reproduce it every time):
r0 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x1)
write$binfmt_elf64(r0, &(0x7f0000000240)={{0x7f, 0x45, 0x4c, 0x46, 0x40,
0x2, 0x2, 0xffffffff, 0xffffffffffff374c, 0x3, 0x0, 0x80000001, 0x103,
0x40, 0x22e, 0x26, 0x1, 0x38, 0x2, 0xa23, 0x1, 0x2}, [{0x6474e557, 0x5,
0x6, 0x2, 0x9, 0x9, 0x6c3, 0x1ff}], "", [[], [], [], []]}, 0x478)
ioctl$EVIOCGSW(0xffffffffffffffff, 0x8040451b, &(0x7f0000000040)=""/7)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x1)
openat$smack_task_current(0xffffffffffffff9c,
&(0x7f0000000040)='/proc/self/attr/current\x00', 0x2, 0x0)
ioctl$EVIOCSABS0(r1, 0x401845c0, &(0x7f0000000000)={0x4, 0x10000, 0x4,
0xd1, 0x81, 0x3})
eventfd(0x1ff)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2,
0x200)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x1)
Typecast int to long to fix the issue.
Signed-off-by: liujian <liujian56@huawei.com>
---
drivers/input/input.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..24615ef 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -59,14 +59,17 @@ static inline int is_event_supported(unsigned int code,
static int input_defuzz_abs_event(int value, int old_val, int fuzz)
{
if (fuzz) {
- if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
+ if (value > (long)old_val - fuzz / 2 &&
+ value < (long)old_val + fuzz / 2)
return old_val;
- if (value > old_val - fuzz && value < old_val + fuzz)
- return (old_val * 3 + value) / 4;
+ if (value > (long)old_val - fuzz &&
+ value < (long)old_val + fuzz)
+ return ((long)old_val * 3 + value) / 4;
- if (value > old_val - fuzz * 2 && value < old_val + fuzz * 2)
- return (old_val + value) / 2;
+ if (value > (long)old_val - fuzz * 2 &&
+ value < (long)old_val + fuzz * 2)
+ return ((long)old_val + value) / 2;
}
return value;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-11-01 21:56 UTC (permalink / raw)
To: Lubomir Rintel
Cc: linux-kernel, linux-clk, devicetree, linux-input, Rob Herring,
Mark Rutland, Dmitry Torokhov, Michael Turquette, Stephen Boyd
In-Reply-To: <20180910112654.42061-1-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
Hi!
> This makes keyboard/touchpad work on a DT MMP2 platform.
For the series:
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH] input: atkbd: clean up indentation issue, add missing tab in an if statement
From: Colin King @ 2018-11-01 15:12 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to clean up indentation issues, add missing tab
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/input/keyboard/atkbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 7e75835e220f..850bb259c20e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -841,7 +841,7 @@ static int atkbd_select_set(struct atkbd *atkbd, int target_set, int allow_extra
if (param[0] != 3) {
param[0] = 2;
if (ps2_command(ps2dev, param, ATKBD_CMD_SSCANSET))
- return 2;
+ return 2;
}
ps2_command(ps2dev, param, ATKBD_CMD_SETALL_MBR);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-11-01 13:47 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Hi!
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
Huh. You see that crazy sed magic script?
sed "s/^\(0*20: .... .... .... .... .... ....\) $BEFORE/\1 $AFTER/" |
Do this with the regular expression. My xxd actually has different
number of leading zeros, and so fails...
And with that fixed, I have self-compiled kernel that actually
boots. Yuppie!
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 3/3] asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
According to Asus firmware engineers, the meaning of these codes is only
to notify the OS that the screen brightness has been turned on/off by
the EC. This does not match the meaning of KEY_DISPLAYTOGGLE /
KEY_DISPLAY_OFF, where userspace is expected to change the display
brightness.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-nb-wmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 5a00a7665f9b..b6f2ff95c3ed 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -442,8 +442,6 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
{ KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
{ KE_KEY, 0x32, { KEY_MUTE } },
- { KE_KEY, 0x33, { KEY_DISPLAYTOGGLE } }, /* LCD on */
- { KE_KEY, 0x34, { KEY_DISPLAY_OFF } }, /* LCD off */
{ KE_KEY, 0x35, { KEY_SCREENLOCK } },
{ KE_KEY, 0x40, { KEY_PREVIOUSSONG } },
{ KE_KEY, 0x41, { KEY_NEXTSONG } },
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
When the OS registers to handle events from the display off hotkey the
EC will send a notification with 0x35 for every key press, independent
of the backlight state.
The behavior of this key on Windows, with the ATKACPI driver from Asus
installed, is turning off the backlight of all connected displays with a
fading effect, and any cursor input or key press turning the backlight
back on. The key press or cursor input that wakes up the display is also
passed through to the application under the cursor or under focus.
The key that matches this behavior the closest is KEY_SCREENLOCK.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-nb-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index db2af09067db..5a00a7665f9b 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -444,6 +444,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, 0x32, { KEY_MUTE } },
{ KE_KEY, 0x33, { KEY_DISPLAYTOGGLE } }, /* LCD on */
{ KE_KEY, 0x34, { KEY_DISPLAY_OFF } }, /* LCD off */
+ { KE_KEY, 0x35, { KEY_SCREENLOCK } },
{ KE_KEY, 0x40, { KEY_PREVIOUSSONG } },
{ KE_KEY, 0x41, { KEY_NEXTSONG } },
{ KE_KEY, 0x43, { KEY_STOPCD } }, /* Stop/Eject */
--
2.19.1
^ permalink raw reply related
* [PATCH 1/3] asus-wmi: Tell the EC the OS will handle the display off hotkey
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>
In the past, Asus firmwares would change the panel backlight directly
through the EC when the display off hotkey (Fn+F7) was pressed, and
only notify the OS of such change, with 0x33 when the LCD was ON and
0x34 when the LCD was OFF. These are currently mapped to
KEY_DISPLAYTOGGLE and KEY_DISPLAY_OFF, respectively.
Most recently the EC on Asus most machines lost ability to toggle the
LCD backlight directly, but unless the OS informs the firmware it is
going to handle the display toggle hotkey events, the firmware still
tries change the brightness through the EC, to no effect. The end result
is a long list (at Endless we counted 11) of Asus laptop models where
the display toggle hotkey does not perform any action. Our firmware
engineers contacts at Asus were surprised that there were still machines
out there with the old behavior.
Calling WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2) on the _WDG device
tells the firmware that it should let the OS handle the display toggle
event, in which case it will simply notify the OS of a key press with
0x35, as shown by the DSDT excerpts bellow.
Scope (_SB)
{
(...)
Device (ATKD)
{
(...)
Name (_WDG, Buffer (0x28)
{
/* 0000 */ 0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11,
/* 0008 */ 0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66,
/* 0010 */ 0x4E, 0x42, 0x01, 0x02, 0x35, 0xBB, 0x3C, 0x0B,
/* 0018 */ 0xC2, 0xE3, 0xED, 0x45, 0x91, 0xC2, 0x4C, 0x5A,
/* 0020 */ 0x6D, 0x19, 0x5D, 0x1C, 0xFF, 0x00, 0x01, 0x08
})
Method (WMNB, 3, Serialized)
{
CreateDWordField (Arg2, Zero, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
Local0 = (Arg1 & 0xFFFFFFFF)
(...)
If ((Local0 == 0x53564544))
{
(...)
If ((IIA0 == 0x00050011))
{
If ((IIA1 == 0x02))
{
^^PCI0.SBRG.EC0.SPIN (0x72, One)
^^PCI0.SBRG.EC0.BLCT = One
}
Return (One)
}
}
(...)
}
(...)
}
(...)
}
(...)
Scope (_SB.PCI0.SBRG.EC0)
{
(...)
Name (BLCT, Zero)
(...)
Method (_Q10, 0, NotSerialized) // _Qxx: EC Query
{
If ((BLCT == Zero))
{
Local0 = One
Local0 = RPIN (0x72)
Local0 ^= One
SPIN (0x72, Local0)
If (ATKP)
{
Local0 = (0x34 - Local0)
^^^^ATKD.IANE (Local0)
}
}
ElseIf ((BLCT == One))
{
If (ATKP)
{
^^^^ATKD.IANE (0x35)
}
}
}
(...)
}
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/platform/x86/asus-wmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index b52b192a4f16..c25b946bb602 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -2150,7 +2150,8 @@ static int asus_wmi_add(struct platform_device *pdev)
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
- }
+ } else
+ err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
status = wmi_install_notify_handler(asus->driver->event_guid,
asus_wmi_notify, asus);
--
2.19.1
^ permalink raw reply related
* [PATCH 0/3] Fix display off hotkey on Asus machines
From: João Paulo Rechi Vita @ 2018-11-01 0:21 UTC (permalink / raw)
To: Corentin Chary, Darren Hart, Andy Shevchenko, acpi4asus-user,
platform-driver-x86
Cc: hadess, Dmitry Torokhov, linux-input, linux-kernel, linux,
João Paulo Rechi Vita
Asus laptops have a hotkey function on the F7 key to turn the display
backlight OFF, labeled with a screen with a X inside, as shown on
https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
This hotkey worked on very few Asus models, where the EC acts on the
backlight and input events are generated only to notify userspace of the
backlight status. On these machines the first hotkey press turns the
display backlight OFF and notifies the OS with 0x34, which asus-nb-wmi
forwards to userspace as KEY_DISPLAY_OFF, and a second press turns it
back ON and notifies the OS with 0x33, which asus-nb-wmi forwards to
userspace as KEY_DISPLAYTOGGLE. No other keys turn the display backlight
back ON, but their input is forwarded normally to the application under
focus.
But for the majority of models, the EC actually does not act on the
backlight and we simply get a 0x33 notification every time the key is
pressed, or alternating values of 0x33 / 0x34. We have confirmed this
behavior on the following models: E203NAS, GL553VE, X441NC, X441UVK,
X541UVK, X555DG, X555UB, X555UQ, X560UD, X570ZD and X705FD, and the DSDT
on these machines and the working one (only confirmed on N552VW) is the
same for the query involved here.
After trying to get information from Asus for quite some time on how
this works on Windows, we finally recently got a contact that was able
to give us a definitive answer and a specification for this feature.
According this contact the 0x33 / 0x34 is an old behavior and all newer
machines should only be notifying the OS with 0x35 instead, as newer ECs
don't control the backlight anymore. When a 0x35 notification is
received the OS should act on the display backlight. From the spec
(machine-translated from Chinese):
1.4 Fn+F7
Function introduction
After the user presses Fn + F7, the screen will be closed through the
Windows API. The user will immediately open the screen with the mouse
and keyboard.
The API used can be found in the Sample URL:
https://code.msdn.microsoft.com/windowsdesktop/Coalescable-Timer-Sample-d9da954c
BIOS implementation
Increase Notify code
LCD On: 0x33 (display OSD)
LCD Off: 0x34 (display OSD)
LCD Switch: 0x35 (using API switch)
The behavior on Windows with the ATKACPI driver from Asus installed
matches what is described above, with the hotkey turning OFF the
backlight of all connected displays with a fading effect, and any cursor
input or key press turning the backlight back ON. The key press or
cursor input is passed through to the application under focus or under
the cursor.
With this information from the spec, a simple analysis of the DSDT
(pasted on the first commit of this series) shows that in order to have
the firmware notify the OS with 0x35 and have the OS act on the
backlight, we need to call WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2)
on the _WDG device. Then we can simply map that scan code to the
appropriate key code in the driver.
In include/uapi/linux/input-event-codes.h KEY_DISPLAY_OFF is defined as
"display device to off state", but it is not actually handled by
userspace on a GNOME+Xorg stack. There are also KEY_SCREENSAVER and
KEY_SCREENLOCK / KEY_COFFEE. The former seems to be ignored by userspace
as well (and its value is higher than 255 so it can't be handled by Xorg
IIUC), and the later is mapped to XF86ScreenSaver by Xorg and triggers
the lock screen action on GNOME. KEY_SCREENLOCK seems to be what closest
matches the behavior described above in a Xorg world. I am not sure if
any of this changes with Wayland, so any clarifications in that regard
would be greatly appreciated.
João Paulo Rechi Vita (3):
asus-wmi: Tell the EC the OS will handle the display off hotkey
asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
drivers/platform/x86/asus-nb-wmi.c | 3 +--
drivers/platform/x86/asus-wmi.c | 3 ++-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: Logitech high-resolution scrolling..
From: Nestor Lopez Casado @ 2018-10-31 13:47 UTC (permalink / raw)
To: hcutts
Cc: Linus Torvalds, peter.hutterer, jikos, Benjamin Tissoires,
open list:HID CORE LAYER, linux-kernel
In-Reply-To: <CA+jURctDNnVjKEZD6jm3ACv1r8_Me9f+6T_aRiApR=Nd_+upvw@mail.gmail.com>
Hi guys,
I've read the discussion, I think I understand the problem and I'll
get back to this thread with more information as soon as I've got some
internal feedback.
BTW, lovely to see so many MX Anywhere 2 users :)
-nestor
On Tue, Oct 30, 2018 at 6:48 PM Harry Cutts <hcutts@chromium.org> wrote:
>
> Thanks for the analysis, Peter.
>
> On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > IMO this is a lost battle because you cannot know when the ratchet is
> > enabled or not (at least not on all mice). Users switch between ratchet and
> > freewheeling time and once you're out of one mode, you have no reference
> > to the other mode's reset point anymore.
>
> It would be a lost battle, if it weren't for the fact that on all the
> mice I've tested, putting the wheel back into clicky mode causes the
> wheel to jump to the nearest notch resting point, which should mean
> that the remainder resets to 0 (or maybe ±1 if the mechanism is worn).
>
> > So my suggestion is to combine Linus' reset with your approach and use the
> > center-point for the trigger. This gives us a few events to slide and still
> > do the right thing, and any direction change will reset anyway. Biggest
> > drawback is that the first event after a direction change is triggered
> > faster than the next event. Otherwise it feels correct to me, both in
> > free-wheeling and in ratchet mode now.
>
> This sounds like a reasonable approach if we find that we can't keep
> the triggering point consistent.
>
> > Also, WTF moment: I managed to get the mouse into a state where it would
> > only give me 1 hi-res event per notch movement but failed to reproduce that
> > again.
>
> Interesting; let me know if you manage to reliably reproduce it. The
> only time I've encountered this in the past was when connecting to the
> mouse over BLE, where we don't seem to be able to detect if the mouse
> is power cycled (meaning that the mouse resets to low-res mode but the
> kernel is still expecting high-res reports). I held off on enabling
> high-res scrolling over Bluetooth for this reason.
>
> On Tue, 30 Oct 2018 at 09:29, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > I wonder if there's some docs on what Logitech does internally in the
> > mouse. It might involve a timeout (ie "if not moving for a while, do
> > the rounding _and_ reset), which would probably be too expensive to do
> > on the host side.
>
> I've been wondering this as well. Nestor (CCed), is there anything you
> can tell us about this?
>
> Harry Cutts
> Chrome OS Touch/Input team
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 12:46 UTC (permalink / raw)
To: James Cameron
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181031033746.GF8698@us.netrek.org>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
Hi!
> > https://github.com/hackerspace/olpc-xo175-buildroot/releases
> >
> > Here's a SD card image that works for me. The topmost commit in the
> > same repository is the build configuration that was used to generate
> > it:
> >
> > https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
> >
> > Note it is only going to boot off the SD card, because the root=
> > argument is hardwired in the devicetree. Sorry about that -- I built
> > the image before I noticed you're booting off an USB stick and I don't
> > have the resources to regenerate the image at the moment.
>
> Your image does boot for me - after changing features on
> filesystem.
>
> http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg)
>
> dumpe2fs of your image filesystem features; has_journal ext_attr
> resize_inode dir_index filetype flex_bg sparse_super large_file
> huge_file dir_nlink extra_isize metadata_csum, and flags;
> signed_directory_hash.
>
> dumpe2fs of my image filesystem features; has_journal ext_attr
> resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg
> dir_nlink extra_isize, and flags; unsigned_directory_hash.
>
> Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from
> e2fsprogs 1.42.5.
>
> I'll look at the microSD card errors; by trying another one.
Success, too... after re-doing the filesystem with local mkfs.
One thing I noticed: olpc-battery/voltage_max_design is lower than
voltage normally reported by voltage_now.
I'll play with it some more
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 12:29 UTC (permalink / raw)
To: James Cameron
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181030235430.GF30863@us.netrek.org>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
Hi!
> > But I don't get kernel messages during boot:
> >
> > OLPC 1B1, 512 MiB memory...
> > OpenFirmware Q4C02 EC Frimware 0.3.02
> >
> > Type any key to interrupt...
> > (but keys do not interrupt anything, ouch).
> > Warning... partition type is 0xb...
> > Boot device: /usb/disk:\boot\olpc.fth Arguments:
> > Boot device ....
> > Warning... partition type is 0xb...
>
> That firmware has problems with USB drives. Please upgrade to Q4D38.
> Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware
Let me try that... Upgrading firmware said "USB drive" so I placed
bootfw.zip on usb drive. It did quite a show, but I believe it said
that my firmware is up to date?
It all ended with "activation lease not found" message. Let me retry?
Same result.
Let me try "upgrading firmware" with SD card. It seems to work with SD
card. Holding down both "yes" and "no" keys during boot results in
more useful messages... good. I have now updated firmware, and it even
fixed my previous boot problem. Good.
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Pavel Machek @ 2018-10-31 11:54 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]
Hi!
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> > > > I didn't test it yet -- will do when I get home in the evening.
> > > > But
> > > > chances are it's good enough and I guess you'd be able to get it
> > > > working even if I messed up some details.
> >
> > Instruction say make, but you really need to do make zImage and make
> > mmp2-olpc-xo-1-75.dtb .
>
> Have you tried? I'm typically doing just a plain "make".
>
> According to "make help", a plain "make" (assuming it's equivalent to
> "make all") includes "zImage" and "dtbs" targets.
I believe I did, but not 100% sure.
> > Instructions say "make -j", which is nice way to crash a machine. I
> > suggest "make -j 8" :-).
>
> Holy... what sort of a machine do you have?
Thinkpad X220. Is it too big or too small? :-). 4 threads, so I
usually use -j 5, but -j 8 should be for my notebook and also bigger
servers.
> > Ok, I think I followed the instructions. I am using empty root
> > filesystem, just with /boot -- want to see kernel messages first
> > before I mess with the userland.
> >
> > But I don't get kernel messages during boot:
> >
> > OLPC 1B1, 512 MiB memory...
> > OpenFirmware Q4C02 EC Frimware 0.3.02
>
> "Frimware" -- I assume you don't have a serial console hooked on? :)
Not :-(. Altrough.. maybe I do have that cable somewhere, I just never
used it.
> > Type any key to interrupt...
> > (but keys do not interrupt anything, ouch).
>
> In my version of the OLPC OF the routine is replaced with one that only
> accepts the Escape key, because kids like to press random keys without
> really wanting a shell. Maybe try that one?
Ok, will try.
> > And that's it, cursor and no kernel messages.
> >
> > Any ideas?
> >
> > Could I get prepared binary zImage for testing?
>
> https://github.com/hackerspace/olpc-xo175-buildroot/releases
>
> Here's a SD card image that works for me. The topmost commit in the
> same repository is the build configuration that was used to generate
> it:
Kernel works for me with this one. (First boot userland boots, then
blinking cursor; next boot filesystem is corrupted. Hmm.) Feel free to
add "Tested-by:" to patches this uses.
> Note it is only going to boot off the SD card, because the root=
> argument is hardwired in the devicetree. Sorry about that -- I built
> the image before I noticed you're booting off an USB stick and I don't
> have the resources to regenerate the image at the moment.
No problem, I have SD cards here, too.
> If this won't boot for you, we may need fixes for older FW. Until then
> it might be a good idea if you just update to the latest one (it is as
> easy as booting the last version of the stock distro with a charged
> battery pack).
I'd need more instructions for firmware update. Or maybe ... lets
ignore that. SD card is fine, and I don't want to brick it.
I already broken it enough that keys need to be held during boot (or
it does not boot).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: James Cameron @ 2018-10-31 3:37 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Pavel Machek, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <2761d7e31cf7118492e466a5249303c92f68049b.camel@v3.sk>
G'day,
Success, see below.
On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote:
> Hello Pavel,
>
> On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> > > > I didn't test it yet -- will do when I get home in the evening.
> > > > But
> > > > chances are it's good enough and I guess you'd be able to get it
> > > > working even if I messed up some details.
> >
> > [...]
> > Could I get prepared binary zImage for testing?
>
> https://github.com/hackerspace/olpc-xo175-buildroot/releases
>
> Here's a SD card image that works for me. The topmost commit in the
> same repository is the build configuration that was used to generate
> it:
>
> https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
>
> Note it is only going to boot off the SD card, because the root=
> argument is hardwired in the devicetree. Sorry about that -- I built
> the image before I noticed you're booting off an USB stick and I don't
> have the resources to regenerate the image at the moment.
Your image does boot for me - after changing features on
filesystem.
http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg)
dumpe2fs of your image filesystem features; has_journal ext_attr
resize_inode dir_index filetype flex_bg sparse_super large_file
huge_file dir_nlink extra_isize metadata_csum, and flags;
signed_directory_hash.
dumpe2fs of my image filesystem features; has_journal ext_attr
resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg
dir_nlink extra_isize, and flags; unsigned_directory_hash.
Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from
e2fsprogs 1.42.5.
I'll look at the microSD card errors; by trying another one.
Fantastic progress though, thanks! Wish I were a full time kernel
developer, but so much else to do now.
> If this won't boot for you, we may need fixes for older FW.
Let me know what you need there; with a patch, and if it isn't too
extensive I could spin a new build. We're not producing these models,
so I don't _have_ to keep the factory test code working.
https://github.com/quozl/openfirmware
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: James Cameron @ 2018-10-30 23:54 UTC (permalink / raw)
To: Pavel Machek
Cc: Lubomir Rintel, Dmitry Torokhov, Michael Turquette, Rob Herring,
Mark Rutland, Stephen Boyd, linux-input, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20181030102610.GC21529@amd>
G'day Pavel,
On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening. But
> > > chances are it's good enough and I guess you'd be able to get it
> > > working even if I messed up some details.
>
> Instruction say make, but you really need to do make zImage and make
> mmp2-olpc-xo-1-75.dtb .
>
> Instructions say "make -j", which is nice way to crash a machine. I
> suggest "make -j 8" :-).
>
> Ok, I think I followed the instructions. I am using empty root
> filesystem, just with /boot -- want to see kernel messages first
> before I mess with the userland.
>
> But I don't get kernel messages during boot:
>
> OLPC 1B1, 512 MiB memory...
> OpenFirmware Q4C02 EC Frimware 0.3.02
>
> Type any key to interrupt...
> (but keys do not interrupt anything, ouch).
> Warning... partition type is 0xb...
> Boot device: /usb/disk:\boot\olpc.fth Arguments:
> Boot device ....
> Warning... partition type is 0xb...
That firmware has problems with USB drives. Please upgrade to Q4D38.
Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware
I'm firmware releaser and signer.
> And that's it, cursor and no kernel messages.
>
> Any ideas?
>
> Could I get prepared binary zImage for testing?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
From: Lubomir Rintel @ 2018-10-30 19:40 UTC (permalink / raw)
To: Pavel Machek
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, James Cameron, linux-input, devicetree,
linux-kernel, linux-clk
In-Reply-To: <20181030102610.GC21529@amd>
Hello Pavel,
On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening.
> > > But
> > > chances are it's good enough and I guess you'd be able to get it
> > > working even if I messed up some details.
>
> Instruction say make, but you really need to do make zImage and make
> mmp2-olpc-xo-1-75.dtb .
Have you tried? I'm typically doing just a plain "make".
According to "make help", a plain "make" (assuming it's equivalent to
"make all") includes "zImage" and "dtbs" targets.
>
> Instructions say "make -j", which is nice way to crash a machine. I
> suggest "make -j 8" :-).
Holy... what sort of a machine do you have?
> Ok, I think I followed the instructions. I am using empty root
> filesystem, just with /boot -- want to see kernel messages first
> before I mess with the userland.
>
> But I don't get kernel messages during boot:
>
> OLPC 1B1, 512 MiB memory...
> OpenFirmware Q4C02 EC Frimware 0.3.02
"Frimware" -- I assume you don't have a serial console hooked on? :)
Doesn't matter though, your OF doesn't seem to even get to load the
kernel anyways. And the framebuffer console (though only by the means
of a hacked pxa168fb for the time being, no armada drm yet) works.
Here's my bootup banner:
OLPC 1B1, 800 MHz, 512 MiB memory, 4 GB internal storage...
OpenFirmware Q4D38 EC Firmware 1.0.01 2018-10-30 19:11:36 UTC
I seem to have a bit newer OF.
> Type any key to interrupt...
> (but keys do not interrupt anything, ouch).
In my version of the OLPC OF the routine is replaced with one that only
accepts the Escape key, because kids like to press random keys without
really wanting a shell. Maybe try that one?
Although my prompt is also a bit different: "Type the Esc key to
interrupt automatic startup"
> Warning... partition type is 0xb...
> Boot device: /usb/disk:\boot\olpc.fth Arguments:
> Boot device ....
> Warning... partition type is 0xb...
Maybe the older version wouldn't support a VFAT volume, hence the
complains about the id=0xb volume? Try ext3?
>
> And that's it, cursor and no kernel messages.
>
> Any ideas?
>
> Could I get prepared binary zImage for testing?
https://github.com/hackerspace/olpc-xo175-buildroot/releases
Here's a SD card image that works for me. The topmost commit in the
same repository is the build configuration that was used to generate
it:
https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch
Note it is only going to boot off the SD card, because the root=
argument is hardwired in the devicetree. Sorry about that -- I built
the image before I noticed you're booting off an USB stick and I don't
have the resources to regenerate the image at the moment.
If this won't boot for you, we may need fixes for older FW. Until then
it might be a good idea if you just update to the latest one (it is as
easy as booting the last version of the stock distro with a charged
battery pack).
> Thanks.
>
>
> Pavel
Take care
Lubo
^ permalink raw reply
* Re: [PATCH v5 3/8] dt-bindings: regulator: document stpmic1 pmic regulators
From: Rob Herring @ 2018-10-30 19:34 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1540830122-2577-4-git-send-email-p.paillet@st.com>
On Mon, Oct 29, 2018 at 04:22:05PM +0000, Pascal PAILLET-LME wrote:
> The STPMIC1 regulators supply power to the application processor as well as
> to the external system peripherals such as DDR, Flash memories and system
> devices.
>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
> ---
> changes in v5:
> * describe regulator-active-discharge is available for power switches
> * remove interrupt parents
>
> .../bindings/regulator/st,stpmic1-regulator.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> new file mode 100644
> index 0000000..5adc938
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> @@ -0,0 +1,67 @@
> +STMicroelectronics STPMIC1 Voltage regulators
> +
> +Regulator Nodes are optional depending on needs.
> +
> +Available Regulators in STPMIC1 device are:
> + - buck1 for Buck BUCK1
> + - buck2 for Buck BUCK2
> + - buck3 for Buck BUCK3
> + - buck4 for Buck BUCK4
> + - ldo1 for LDO LDO1
> + - ldo2 for LDO LDO2
> + - ldo3 for LDO LDO3
> + - ldo4 for LDO LDO4
> + - ldo5 for LDO LDO5
> + - ldo6 for LDO LDO6
> + - vref_ddr for LDO Vref DDR
> + - boost for Buck BOOST
> + - pwr_sw1 for VBUS_OTG switch
> + - pwr_sw2 for SW_OUT switch
> +
> +Switches are fixed voltage regulators with only enable/disable capability.
> +
> +Optional properties:
> +- st,mask-reset: mask reset for this regulator: the regulator configuration
> + is maintained during pmic reset.
> +- regulator-pull-down: enable high pull down
> + if not specified light pull down is used
> +- regulator-over-current-protection:
> + if set, all regulators are switched off in case of over-current detection
> + on this regulator,
> + if not set, the driver only sends an over-current event.
> +- interrupt-parent: phandle to the parent interrupt controller
This is not needed as the parent is a parent node with
'interrupt-controller' property.
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
> +- interrupts: index of current limit detection interrupt
> +- <regulator>-supply: phandle to the parent supply/regulator node
> + each regulator supply can be described except vref_ddr.
> +- regulator-active-discharge: can be used on pwr_sw1 and pwr_sw2.
> +
> +Example:
> +regulators {
> + compatible = "st,stpmic1-regulators";
> +
> + ldo6-supply = <&v3v3>;
> +
> + vdd_core: buck1 {
> + regulator-name = "vdd_core";
> + interrupts = <IT_CURLIM_BUCK1 0>;
> + st,mask-reset;
> + regulator-pull-down;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1200000>;
> + };
> +
> + v3v3: buck4 {
> + regulator-name = "v3v3";
> + interrupts = <IT_CURLIM_BUCK4 0>;
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + v1v8: ldo6 {
> + regulator-name = "v1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-over-current-protection;
> + };
> +};
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: mfd: document stpmic1
From: Rob Herring @ 2018-10-30 19:32 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1540830122-2577-2-git-send-email-p.paillet@st.com>
On Mon, 29 Oct 2018 16:22:04 +0000, Pascal PAILLET-LME wrote:
> stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
> regulators, 3 power switches, a watchdog and an input for a power on key.
>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
> ---
> changes in v5:
> * removed st properties
> * added buck modes definitions in the header
>
> .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++++++++++++++++++
> include/dt-bindings/mfd/st,stpmic1.h | 50 ++++++++++++++++++
> 2 files changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: Logitech high-resolution scrolling..
From: Harry Cutts @ 2018-10-30 17:48 UTC (permalink / raw)
To: torvalds
Cc: Peter Hutterer, jikos, benjamin.tissoires, linux-input,
linux-kernel, Nestor Lopez Casado
In-Reply-To: <CAHk-=wg5m-zt0Kc0o1mOaZSKUsWbjud9xjZssoHAth=ZxoAhQg@mail.gmail.com>
Thanks for the analysis, Peter.
On Mon, 29 Oct 2018 at 23:27, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> IMO this is a lost battle because you cannot know when the ratchet is
> enabled or not (at least not on all mice). Users switch between ratchet and
> freewheeling time and once you're out of one mode, you have no reference
> to the other mode's reset point anymore.
It would be a lost battle, if it weren't for the fact that on all the
mice I've tested, putting the wheel back into clicky mode causes the
wheel to jump to the nearest notch resting point, which should mean
that the remainder resets to 0 (or maybe ±1 if the mechanism is worn).
> So my suggestion is to combine Linus' reset with your approach and use the
> center-point for the trigger. This gives us a few events to slide and still
> do the right thing, and any direction change will reset anyway. Biggest
> drawback is that the first event after a direction change is triggered
> faster than the next event. Otherwise it feels correct to me, both in
> free-wheeling and in ratchet mode now.
This sounds like a reasonable approach if we find that we can't keep
the triggering point consistent.
> Also, WTF moment: I managed to get the mouse into a state where it would
> only give me 1 hi-res event per notch movement but failed to reproduce that
> again.
Interesting; let me know if you manage to reliably reproduce it. The
only time I've encountered this in the past was when connecting to the
mouse over BLE, where we don't seem to be able to detect if the mouse
is power cycled (meaning that the mouse resets to low-res mode but the
kernel is still expecting high-res reports). I held off on enabling
high-res scrolling over Bluetooth for this reason.
On Tue, 30 Oct 2018 at 09:29, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I wonder if there's some docs on what Logitech does internally in the
> mouse. It might involve a timeout (ie "if not moving for a while, do
> the rounding _and_ reset), which would probably be too expensive to do
> on the host side.
I've been wondering this as well. Nestor (CCed), is there anything you
can tell us about this?
Harry Cutts
Chrome OS Touch/Input team
^ permalink raw reply
* Re: Logitech high-resolution scrolling..
From: Linus Torvalds @ 2018-10-30 16:29 UTC (permalink / raw)
To: Peter Hutterer
Cc: Harry Cutts, Jiri Kosina, Benjamin Tissoires, linux-input,
Linux Kernel Mailing List
In-Reply-To: <20181030062657.GA5380@jelly>
On Mon, Oct 29, 2018 at 11:27 PM Peter Hutterer
<peter.hutterer@who-t.net> wrote:
>
> Other issues I found with an MX Anywhere 2S is that on slow scroll and in
> ratchet mode we get some scroll jitter. In ratchet mode we can get this
> sequence if you scroll just past the notch and it snaps back:
> [1, 1, 1, 1, 1, 1, 1, 1, -1]
> That's quite easy to trigger. In free-wheel mode we may get the same for
> slow motion due to human finger jitter (the Anywhere 2S didn't have HW
> jitter, but other devices may). So a perceived-consistent scroll motion may
> really look like this:
> [1, 1, 1, 1, 1, -1, 1, 1]
> Hard to triggger but when it does, it feels like we're dropping events.
> The former isn't that much of an issue as long as the ratchet is enabled so
> you get the haptic feedback and we (usually) don't drop events.
Both of these actually argue that doing the reset on direction change
can be a real problem.
But equally clearly, _not_ doing the reset is unacceptable too.
I wonder if there's some docs on what Logitech does internally in the
mouse. It might involve a timeout (ie "if not moving for a while, do
the rounding _and_ reset), which would probably be too expensive to do
on the host side.
Linus
^ permalink raw reply
* Re: Logitech high-resolution scrolling..
From: Mauro Carvalho Chehab @ 2018-10-30 15:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Harry Cutts, Benjamin Tissoires, Jiri Kosina, linux-input,
Linux Kernel Mailing List
In-Reply-To: <CAHk-=wjisf8Bmgbtf3y0W+Lu58t3nSnvKGc0J=Zo=rmz3eA+Cw@mail.gmail.com>
Em Sun, 28 Oct 2018 14:08:31 -0700
Linus Torvalds <torvalds@linux-foundation.org> escreveu:
> On Sun, Oct 28, 2018 at 12:13 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So the recent change to enable the high-res scrolling really seems a
> > bit *too* extreme.
> >
> > Is there some middle ground that turns the mouse from "look at it
> > sideways and it starts scrolling" to something slightly more
> > reasonable?
>
> Actually, I think the bug may be in the generic HID high-resolution
> scrolling code, and I only notice because the Logitech support means
> that now I see it.
>
> In particular, if you look at hid_scroll_counter_handle_scroll(),
> you'll notice that it tries to turn a high-res scroll event into a
> regular wheel event by using the resolution_multiplier.
>
> But that code looks really broken. It tries to react to a "half
> multiplier" thing:
>
> int threshold = counter->resolution_multiplier / 2;
> ..
> counter->remainder += hi_res_value;
> if (abs(counter->remainder) >= threshold) {
>
> and that's absolutely and entirely wrong.
>
> Imagine that the high-res wheel counter has just moved a bit up (by
> one high-res) tick, so now it's at the half-way mark to the
> resolution_multiplier, and we scroll up by one:
>
> low_res_scroll_amount =
> counter->remainder / counter->resolution_multiplier
> + (hi_res_value > 0 ? 1 : -1);
> input_report_rel(counter->dev, REL_WHEEL,
> low_res_scroll_amount);
>
> and then correct for it:
>
> counter->remainder -=
> low_res_scroll_amount * counter->resolution_multiplier;
>
> now we went from "half resolution multiplier positive" to "half negative".
>
> Which means that next time that the high-res event happens by even
> just one high-resolution tick in the other direction, we'll now
> generate a low-resolution scroll event in the other direction.
>
> In other words, that function results in unstable behavior. Tiny tiny
> movements back-and-forth in the high-res wheel events (which could be
> just because either the sensor is unstable, or the wheel is wiggling
> imperceptibly) can result in visible movement in the low-res
> ("regular") wheel reporting.
>
> There is no "damping" function, in other words. Noise in the high
> resolution reading can result in noise in the regular wheel reporting.
>
> So that threshold handling needs to be fixed, I feel. Either get rid
> of it entirely (you need to scroll a *full* resolution_multiplier to
> get a regular wheel event), or the counter->remainder needs to be
> *cleared* when a wheel event has been sent so that you don't get into
> the whole "back-and-forth" mode.
>
> Or some other damping model. I suspect there are people who have
> researched what the right answer is, but I guarantee that the current
> code is not the right answer.
>
> I suspect this also explains why I *sometimes* see that "just moving
> the mouse sends wheel events", and at other times don't. It needs to
> get close to that "half a resolution multiplier" stage to get into the
> bad cases, but then tiny tiny perturbations can cause unstable
> behavior.
>
> I can't be the only person seeing this, but I guess the Logitech mouse
> is right now the only one that uses the new generic HID code, and I
> guess not a lot of people have been *using* it.
I remember I submitted in the past some patches adding a different event
for the high scroll mode. I have myself a MX Anywhere 2, and even wrote
some patches for Solaar[1] in order to allow selecting between low
res and high res wheel modes.
The problem I faced, on that time, was similar to yours: when the
high res wheel was enabled, it was very hard to control the mouse,
specially when using the wheel in "free" mode (with I do).
I remember that the patchset I sent was not actually applied, but I
didn't followed what happened after that (got sidetracked by
something else).
[1] https://github.com/pwr/Solaar
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v5 7/8] dt-bindings: watchdog: document stpmic1 pmic watchdog
From: Guenter Roeck @ 2018-10-30 13:17 UTC (permalink / raw)
To: Pascal PAILLET-LME, dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, wim@linux-watchdog.org,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1540830122-2577-8-git-send-email-p.paillet@st.com>
On 10/29/18 9:22 AM, Pascal PAILLET-LME wrote:
> The stpmic1 PMIC embeds a watchdog which is disabled by default.
> In case of watchdog, the PMIC goes off.
>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> changes in v5: nothing
>
> Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
> new file mode 100644
> index 0000000..7cc1407
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
> @@ -0,0 +1,11 @@
> +STMicroelectronics STPMIC1 Watchdog
> +
> +Required properties:
> +
> +- compatible : should be "st,stpmic1-wdt"
> +
> +Example:
> +
> +watchdog {
> + compatible = "st,stpmic1-wdt";
> +};
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox