Re: Regression since commit 92bac83

[Hans de Goede]

Hi,

On 19-10-15 01:59, Larry Finger wrote:

Hi,

I recently upgraded the kernel in a Dell Latitude D600 and found that the touchpad clicks 
failed. The problem was bisected to commit 92bac83dd79e60e65c475222e41a992a70434beb 
("Input: alps - non interleaved V2 dualpoint has separate stick button bits"). 
The laptop has a combination touchpad and control stick. For this device, the following 
values are found:

priv->protoversion is 0x200 (ALPS_PROTO_V2)
priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)

As a result, the new code added in this patch is executed, and left, right, and 
middle are updated. Once this code is introduced, a left click causes some 
event as it will wake a sleeping screen, but not select any windows or do 
anything useful.

Please advise on what information would be needed to help debug this problem.


Can you build a recent upstream kernel from source, and when building it
comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 2556

if (dmi_name_in_vendors("Dell"))
priv->flags |= ALPS_DELL;

That should fix things, if that fixes things we need to rename the flag
and move to a list of dmi-matched models (rather then vendor) where the new 
behavior
introduced by the patch causing you problems is actually necessary.

Step 1 is confirming that not setting the flag fixes things for you,
if you can get back to us confirming that, then I'll whip up a patch
to switch to model matching (which is not ideal, but seems to be
necessary).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: Re: FocalTech touchpad stops working after suspend

[thatoo]

no, lsmod | grep i8042 , doesn't show anything.

I guess everything is because of this sentence you wrote to me that I
don't understand, "make sure it is a module and not compiled into
kernel". What does it mean??

Le 17/10/2015 21:31, Dmitry Torokhov a écrit :

On Sat, Oct 17, 2015 at 09:11:44PM +0330, Nathanaël/Thatoo wrote:

I tried to follow the solution,

- pm-utils was already installed

- I created the file /etc/pm/config.d/modules
sudo gedit /etc/pm/config.d/modules
and I wrote
SUSPEND_MODULES="i8042"

- Then I tried to suspend using "sudo pm-suspend" or the shortkey 
etc..

but nothing change.

Maybe I have to write more inside /etc/pm/config.d/modules to "unload"
on suspend and then "reload" on resume, no?
Maybe just the line SUSPEND_MODULES="i8042" is not enough but what
should I write?
What means (make sure it is a module and not compiled into kernel)?

Do you see anything if you do "lsmod | grep i8042"?

Thanks.



0x1BA5F17B.asc
Description: application/pgp-keys

Re: [Y2038] [PATCH] hp_sdc: fixed y2038 problem

[Arnd Bergmann]

On Sunday 18 October 2015 17:44:19 WEN Pingbo wrote:
> Two replacements happened in this patch:
> 1. using timespec64 to prevent time overflow in 2038
> 2. using ktime_get_ts64 to avoid wall time issues(leap second, etc)
> 
> Signed-off-by: WEN Pingbo 
> 

The patch looks correct, but I think this could be written a little
simpler and clearer using ktime_get() or ktime_getns().

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] xen: check return value of xenbus_printf

[Insu Yun]

Internally, xenbus_printf uses memory allocation, so it can be failed in
memory pressure.Therefore, xenbus_printf's return should be checked
and properly handled.

Signed-off-by: Insu Yun 
---
 drivers/input/misc/xen-kbdfront.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 23d0549..9d465d7 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -129,8 +129,14 @@ static int xenkbd_probe(struct xenbus_device *dev,
 
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
) < 0)
abs = 0;
-   if (abs)
-   xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", 
"1");
+   if (abs) {
+   ret = xenbus_printf(XBT_NIL, dev->nodename,
+   "request-abs-pointer", "1");
+   if (ret) {
+   pr_warning("xenkbd: can't request abs-pointer");
+   abs = 0;
+   }
+   }
 
/* keyboard */
kbd = input_allocate_device();
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] xen: check return value of xenbus_printf

[Julien Grall]

Hi,

On 19/10/15 15:10, Insu Yun wrote:
> Internally, xenbus_printf uses memory allocation, so it can be failed in
> memory pressure.Therefore, xenbus_printf's return should be checked
> and properly handled.
> 
> Signed-off-by: Insu Yun 
> ---
>  drivers/input/misc/xen-kbdfront.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 23d0549..9d465d7 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -129,8 +129,14 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  
>   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
> ) < 0)
>   abs = 0;
> - if (abs)
> - xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", 
> "1");
> + if (abs) {
> + ret = xenbus_printf(XBT_NIL, dev->nodename,
> + "request-abs-pointer", "1");

The second line of arguments should be aligned to the first parameter. I.e:

xenbus_printf(XBT_NIL, dev->nodename,
  "request-abs-pointer", "1");

See an example in xenkbd_backend_changed.

With that fixed:

Reviewed-by: Julien Grall 

> + if (ret) {
> + pr_warning("xenkbd: can't request abs-pointer");

Note that checkpatch.pl will print a warning here:

WARNING: Prefer pr_warn(... to pr_warning(...
#27: FILE: drivers/input/misc/xen-kbdfront.c:136:
+   pr_warning("xenkbd: can't request abs-pointer");


Although, I'm fine if you don't fix this one.

> + abs = 0;
> + }
> + }
>  
>   /* keyboard */
>   kbd = input_allocate_device();
> 

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7 3/9] Input: goodix - write configuration data to device

[Tirdea, Irina]

> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 14 October, 2015 9:59
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; linux-input@vger.kernel.org; Mark 
> Rutland; Purdila, Octavian; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 3/9] Input: goodix - write configuration data to device
> 
> On Thu, Oct 08, 2015 at 01:19:29PM +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where  is the product id read from the device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch points,
> > interrupt flags, various sensitivity factors and settings for advanced
> > features (like gesture recognition).
> >
> > Before writing the firmware, it is necessary to reset the device. If
> > the device ACPI/DT information does not declare gpio pins (needed for
> > reset), writing the firmware will not be available for these devices.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > Signed-off-by: Octavian Purdila 
> > Signed-off-by: Irina Tirdea 
> > ---
> >  drivers/input/touchscreen/goodix.c | 229 
> > +++--
> >  1 file changed, 196 insertions(+), 33 deletions(-)
> >

> > +/**
> > + * goodix_config_cb - Callback to finish device init
> > + *
> > + * @ts: our goodix_ts_data pointer
> > + *
> > + * request_firmware_wait callback that finishes
> > + * initialization of the device.
> > + */
> > +static void goodix_config_cb(const struct firmware *cfg, void *ctx)
> > +{
> > +   struct goodix_ts_data *ts = (struct goodix_ts_data *)ctx;
> > +   int error;
> > +
> > +   if (cfg) {
> > +   /* send device configuration to the firmware */
> > +   error = goodix_send_cfg(ts, cfg);
> > +   if (error)
> > +   goto err_release_cfg;
> > +   }
> > +   goodix_configure_dev(ts);
> > +
> > +err_release_cfg:
> > +   kfree(ts->cfg_name);
> > +   release_firmware(cfg);
> 
> You need to use completion to signal remove() (and also probably
> suspend/resume in the subsequent patches) that you are done handling
> config, otherwise if you do bind/unbind via sysfs in a tight loop you
> will observe a nice crash.
> 
> Thanks.
> 

Right, missed that. Will fix in next version.

Thanks,
Irina


> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/9] Input: goodix - reset device at init

[mika.westerb...@linux.intel.com]

On Mon, Oct 19, 2015 at 02:32:24PM +, Tirdea, Irina wrote:
> 
> 
> > -Original Message-
> > From: linux-input-ow...@vger.kernel.org 
> > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of
> > mika.westerb...@linux.intel.com
> > Sent: 14 October, 2015 16:44
> > To: Dmitry Torokhov
> > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> > linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > 
> > On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerb...@linux.intel.com 
> > wrote:
> > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote:
> > > > I understand why one might use acpi_dev_add_driver_gpios() to augment
> > > > data in ACPI, however here we have completely different issue: driver
> > > > that expects named gpios gets returned gpio that has nothing to do with
> > > > what it requested, because gpiolib acpi code always falls back to
> > > > unnamed gpio if it does not find named gpio. That can be acceptable if
> > > > driver uses the same con_id for all requests to gpiolib, but is not
> > > > working when driver supplies different con_ids.
> > >
> > > Right, the ACPI fallback ignores con_id completely and uses only the
> > > index.
> > >
> > > AFAIK there is only one driver using ACPI _CRS index method:
> > > sdhci-[acpi|pci].c. If we can convert that to use 
> > > acpi_dev_add_driver_gpios()
> > > to feed names for card detection GPIOs, I think we can remove the
> > > fallback alltogether in favor of named GPIOs for ACPI.
> > 
> > Nah, there seems to be several drivers relying on this already :-/
> 
> Would it be possible to add an optional parameter to the GPIO API
> to specify whether we want to fall back to indexed GPIOs for ACPI?

I don't think it's a good idea to add ACPI specifics to generic APIs.

I went through ACPI enabled drivers calling GPIO APIs and majority of
them are doing this:

static int stk8312_gpio_probe(struct i2c_client *client)
{
struct device *dev;
struct gpio_desc *gpio;
int ret;

if (!client)
return -EINVAL;

dev = >dev;

/* data ready gpio interrupt pin */
gpio = devm_gpiod_get_index(dev, STK8312_GPIO, 0, GPIOD_IN);
if (IS_ERR(gpio)) {
dev_err(dev, "acpi gpio get index failed\n");
return PTR_ERR(gpio);
}

ret = gpiod_to_irq(gpio);
dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);

return ret;
}

We can drop all this because I2C core already handles GpioInt -> interrupt
number translation.

Few drivers are doing something more complex but I think we can still convert
them to use acpi_dev_add_driver_gpios() and eventually get rid of the whole
_CRS index lookup.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] HID: hiddev: change hiddev_connect() to return bool

[Luis de Bethencourt]

On 13/10/15 02:49, Krzysztof Kozlowski wrote:
> 2015-10-09 22:00 GMT+09:00 Luis de Bethencourt :
>> Since hid_connect() only cares about hiddev_connect() succeeding or
>> failing, there is no need for this function to return an int and it can
>> return a bool instead.
> 
> It can return bool but it would not be in line with kernel coding
> style. The hiddev_connect() I believe is an action, so "the function
> should return an error-code integer.".
> 
> Best regards,
> Krzysztof
>


Hi Krysztof,

The idea to switch the function to return bool was offered by Jiri Kosina,
as a result of my initial patch changing the return errno code to ENOMEM.

Considering the return isn't propagated by the only consumer of the function,
and your point about returning an integer being the kernel coding style. It
doesn't make sense to change this function.

Thanks for your review!
Luis
 
>>
>> Suggested-by: Jiri Kosina 
>> Signed-off-by: Luis de Bethencourt 
>> ---
>>
>> Hi,
>>
>> No idea why my local build did not complain about the obvious mistake
>> on the previous version of the patch.
>>
>> Sorry about that,
>> Luis
>>
>>  drivers/hid/hid-core.c  |  2 +-
>>  drivers/hid/usbhid/hiddev.c | 10 +-
>>  include/linux/hid.h |  2 +-
>>  include/linux/hiddev.h  |  2 +-
>>  4 files changed, 8 insertions(+), 8 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: ETPS/2 Elantech Touchpad dies after resume from suspend to RAM

[Mike Mestnik]

Smells like a known issue with gnome, fixed in recent releases.

On Sun, Oct 18, 2015 at 10:59 PM, WBH  wrote:
> [1.] One line summary of the problem:
> ETPS/2 Elantech Touchpad dies after resume from suspend to RAM
>
> [2.] Full description of the problem/report:
> When the system startup, the touchpad works well, but after it resumed from a 
> suspend, the touchpad hardware will disappear from xinput and cat 
> /proc/bus/input/devices.
>
> Before suspend, xinput output
> ⎡ Virtual core pointer id=2 [master pointer (3)]
> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
> ⎜ ↳ USB OPTICAL MOUSE id=10 [slave pointer (2)]
> ⎜ ↳ ETPS/2 Elantech Touchpad id=14 [slave pointer (2)]
> ⎣ Virtual core keyboard id=3 [master keyboard (2)]
> ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
> ↳ Power Button id=6 [slave keyboard (3)]
> ↳ Video Bus id=7 [slave keyboard (3)]
> ↳ Video Bus id=8 [slave keyboard (3)]
> ↳ Sleep Button id=9 [slave keyboard (3)]
> ↳ USB2.0 VGA UVC WebCam id=11 [slave keyboard (3)]
> ↳ Asus WMI hotkeys id=12 [slave keyboard (3)]
> ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
>
> after suspend, the output
> ⎡ Virtual core pointer id=2 [master pointer (3)]
> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
> ⎜ ↳ USB OPTICAL MOUSE id=10 [slave pointer (2)]
> ⎣ Virtual core keyboard id=3 [master keyboard (2)]
> ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
> ↳ Power Button id=6 [slave keyboard (3)]
> ↳ Video Bus id=7 [slave keyboard (3)]
> ↳ Video Bus id=8 [slave keyboard (3)]
> ↳ Sleep Button id=9 [slave keyboard (3)]
> ↳ USB2.0 VGA UVC WebCam id=11 [slave keyboard (3)]
> ↳ Asus WMI hotkeys id=12 [slave keyboard (3)]
> ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
> And you can find that the " ETPS/2 Elantech Touchpad" is missing
> output of dmesg:
> dmesg|grep mouse
> [ 0.512423] mousedev: PS/2 mouse device common for all mice
> [ 1.114531] psmouse serio1: elantech: assuming hardware version 4 (with 
> firmware version 0x381f00)
> [ 1.128082] psmouse serio1: elantech: Synaptics capabilities query result 
> 0x10, 0x14, 0x0e.
>
> After a reboot, everything works well again.
>
> When I using s2disk with this conf file, the touchpad works well after 
> resume. But if the "shutdown method" is set to platform, the hibernate 
> process will hang after snapshotting the system.
> # /etc/uswsusp.conf(5) -- Configuration file for s2disk/s2both
> resume device = /dev/disk/by-uuid/7b13204e-719a-4ee4-a523-909e75b56507
> compress = y
> early writeout = y
> image size = 0
> RSA key file = /etc/uswsusp.key
> shutdown method = shutdown
> compute checksum = y
> suspend loglevel = 1
> max loglevel = 15
>
>
> [3.] Keywords (i.e., modules, networking, kernel):
> [4.] Kernel version (from /proc/version):
> Linux version 4.3.0-040300rc5-generic (kernel@tangerine) (gcc version 4.8.4 
> (Ubuntu 4.8.4-2ubuntu1~14.04) ) #201510111530 SMP Sun Oct 11 19:31:35 UTC 2015
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
> [6.] A small shell script or example program which triggers the
> problem (if possible)
> $ sudo s2ram
>
> [7.] Environment
> Description: Ubuntu 14.04.3 LTS
> Release: 14.04
>
> [7.1.] Software (add the output of the ver_linux script here)
> Linux biscuit 4.3.0-040300rc5-generic #201510111530 SMP Sun Oct 11 19:31:35 
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Gnu C 4.8
> Gnu make 3.81
> binutils 2.24
> util-linux 2.20.1
> mount support
> module-init-tools 15
> e2fsprogs 1.42.9
> pcmciautils 018
> PPP 2.4.5
> Linux C Library 2.19
> Dynamic linker (ldd) 2.19
> Procps 3.3.9
> Net-tools 1.60
> Kbd 1.15.5
> Sh-utils 8.21
> wireless-tools 30
> Modules Loaded drbg ansi_cprng ctr ccm pci_stub vboxpci vboxnetadp vboxnetflt 
> vboxdrv cmac rfcomm bnep binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi 
> asus_nb_wmi asus_wmi mxm_wmi sparse_keymap snd_hda_codec_realtek 
> snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
> snd_pcm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core intel_rapl 
> v4l2_common x86_pkg_temp_thermal videodev intel_powerclamp media coretemp 
> snd_seq_midi arc4 kvm_intel snd_seq_midi_event kvm i915 ath9k 
> crct10dif_pclmul snd_rawmidi crc32_pclmul ath9k_common ghash_clmulni_intel 
> aesni_intel ath9k_hw ath3k aes_x86_64 lrw btusb btrtl gf128mul btbcm 
> glue_helper ath ablk_helper btintel mac80211 cryptd bluetooth drm_kms_helper 
> snd_seq joydev input_leds drm serio_raw snd_seq_device snd_timer i2c_algo_bit 
> cfg80211 fb_sys_fops intel_pch_thermal syscopyarea sysfillrect sysimgblt 
> mei_me lpc_ich snd mei processor_thermal_device intel_soc_dts_iosf soundcore 
> shpchp iosf_mbi ak8975 inv_mpu6050 industrialio_triggered_buffer parport_pc 
> kfifo_buf industrialio wmi ppdev i2c_mux i2c_hid snd_soc_sst_acpi dw_dmac 
> dw_dmac_core video i2c_designware_platform spi_pxa2xx_platform 8250_dw 
> i2c_designware_core 

Re: Regression since commit 92bac83

[Larry Finger]

On 10/19/2015 03:08 AM, Hans de Goede wrote:

Hi,

On 19-10-15 01:59, Larry Finger wrote:

Hi,

I recently upgraded the kernel in a Dell Latitude D600 and found that the
touchpad clicks failed. The problem was bisected to commit
92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
dualpoint has separate stick button bits"). The laptop has a combination
touchpad and control stick. For this device, the following values are found:

priv->protoversion is 0x200 (ALPS_PROTO_V2)
priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)

As a result, the new code added in this patch is executed, and left, right,
and middle are updated. Once this code is introduced, a left click causes some
event as it will wake a sleeping screen, but not select any windows or do
anything useful.

Please advise on what information would be needed to help debug this problem.


Can you build a recent upstream kernel from source, and when building it
comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 2556

 if (dmi_name_in_vendors("Dell"))
 priv->flags |= ALPS_DELL;

That should fix things, if that fixes things we need to rename the flag
and move to a list of dmi-matched models (rather then vendor) where the new
behavior
introduced by the patch causing you problems is actually necessary.

Step 1 is confirming that not setting the flag fixes things for you,
if you can get back to us confirming that, then I'll whip up a patch
to switch to model matching (which is not ideal, but seems to be
necessary).


Thanks for the quick response. Removing the two lines mentioned above restored 
correct touchpad operation with kernel 4.2.0. It seems that the Latitude D600 is 
different than other Dell models.


Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] xen: check return value of xenbus_printf

[Insu Yun]

Signed-off-by: Insu Yun 
---
 drivers/input/misc/xen-kbdfront.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 23d0549..0a9ad2cf 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -129,8 +129,14 @@ static int xenkbd_probe(struct xenbus_device *dev,
 
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
) < 0)
abs = 0;
-   if (abs)
-   xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", 
"1");
+   if (abs) {
+   ret = xenbus_printf(XBT_NIL, dev->nodename,
+   "request-abs-pointer", "1");
+   if (ret) {
+   pr_warning("xenkbd: can't request abs-pointer");
+   abs = 0;
+   }
+   }
 
/* keyboard */
kbd = input_allocate_device();
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

[Benjamin Tissoires]

Dmitry,

ping again on this one :)

any comments?

Cheers,
Benjamin

On Mon, Sep 21, 2015 at 6:45 AM, David Herrmann  wrote:
> Hi Dmitry
>
> Any comment on this?
>
> Thanks
> David
>
> On Tue, Aug 25, 2015 at 5:12 PM, Benjamin Tissoires
>  wrote:
>> This adds two new ioctls, UINPUT_DEV_SETUP and UI_ABS_SETUP, that
>> replaces the old device setup method (by write()'ing "struct
>> uinput_user_dev" to the node). The old method is not easily extendable
>> and requires huge payloads. Furthermore, overloading write() without
>> properly versioned objects is error-prone.
>>
>> Therefore, we introduce two new ioctls to replace the old method.
>> These ioctls support all features of the old method, plus a "resolution"
>> field for absinfo. Furthermore, it's properly forward-compatible to new
>> ABS codes and a growing "struct input_absinfo" structure.
>>
>> UI_ABS_SETUP also allows user-space to skip unknown axes if not set.
>> There is no need to copy the whole array temporarily into the kernel,
>> but instead the caller issues several ioctl where we copy each value
>> manually.
>>
>> Signed-off-by: David Herrmann 
>> Signed-off-by: Benjamin Tissoires 
>> Reviewed-by: David Herrmann 
>> ---
>>
>> Changes from v2:
>> - returned E2BIG when the userspace has been compiled against a newer kernel
>>   than the current one
>> - formatting changes
>> - remove extra memset
>>
>>
>>  drivers/input/misc/uinput.c | 80 +--
>>  include/linux/uinput.h  |  5 +++
>>  include/uapi/linux/uinput.h | 83 
>> +++--
>>  3 files changed, 162 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
>> index 345df9b..7af1e54 100644
>> --- a/drivers/input/misc/uinput.c
>> +++ b/drivers/input/misc/uinput.c
>> @@ -370,8 +370,73 @@ static int uinput_allocate_device(struct uinput_device 
>> *udev)
>> return 0;
>>  }
>>
>> -static int uinput_setup_device(struct uinput_device *udev,
>> -  const char __user *buffer, size_t count)
>> +static int uinput_dev_setup(struct uinput_device *udev,
>> +   struct uinput_setup __user *arg)
>> +{
>> +   struct uinput_setup setup;
>> +   struct input_dev *dev;
>> +   int retval;
>> +
>> +   if (udev->state == UIST_CREATED)
>> +   return -EINVAL;
>> +   if (copy_from_user(, arg, sizeof(setup)))
>> +   return -EFAULT;
>> +   if (!setup.name[0])
>> +   return -EINVAL;
>> +
>> +   dev = udev->dev;
>> +   dev->id = setup.id;
>> +   udev->ff_effects_max = setup.ff_effects_max;
>> +
>> +   kfree(dev->name);
>> +   dev->name = kstrndup(setup.name, UINPUT_MAX_NAME_SIZE, GFP_KERNEL);
>> +   if (!dev->name)
>> +   return -ENOMEM;
>> +
>> +   retval = uinput_validate_absbits(dev);
>> +   if (retval < 0)
>> +   return retval;
>> +
>> +   udev->state = UIST_SETUP_COMPLETE;
>> +   return 0;
>> +}
>> +
>> +static int uinput_abs_setup(struct uinput_device *udev,
>> +   struct uinput_setup __user *arg, size_t size)
>> +{
>> +   struct uinput_abs_setup setup = {};
>> +   struct input_dev *dev;
>> +
>> +   if (size > sizeof(setup))
>> +   return -E2BIG;
>> +   if (udev->state == UIST_CREATED)
>> +   return -EINVAL;
>> +   if (copy_from_user(, arg, size))
>> +   return -EFAULT;
>> +   if (setup.code > ABS_MAX)
>> +   return -ERANGE;
>> +
>> +   dev = udev->dev;
>> +
>> +   input_alloc_absinfo(dev);
>> +   if (!dev->absinfo)
>> +   return -ENOMEM;
>> +
>> +   set_bit(setup.code, dev->absbit);
>> +   dev->absinfo[setup.code] = setup.absinfo;
>> +
>> +   /*
>> +* We restore the state to UIST_NEW_DEVICE because the user has to 
>> call
>> +* UI_DEV_SETUP in the last place before UI_DEV_CREATE to check the
>> +* validity of the absbits.
>> +*/
>> +   udev->state = UIST_NEW_DEVICE;
>> +   return 0;
>> +}
>> +
>> +/* legacy setup via write() */
>> +static int uinput_setup_device_legacy(struct uinput_device *udev,
>> + const char __user *buffer, size_t 
>> count)
>>  {
>> struct uinput_user_dev  *user_dev;
>> struct input_dev*dev;
>> @@ -474,7 +539,7 @@ static ssize_t uinput_write(struct file *file, const 
>> char __user *buffer,
>>
>> retval = udev->state == UIST_CREATED ?
>> uinput_inject_events(udev, buffer, count) :
>> -   uinput_setup_device(udev, buffer, count);
>> +   uinput_setup_device_legacy(udev, buffer, count);
>>
>> mutex_unlock(>mutex);
>>
>> @@ -735,6 +800,12 @@ static long 

Re: [PATCH 03/17] input: tegra-kbc: drop use of IRQF_NO_SUSPEND flag

[Sudeep Holla]

Hi Dmitry,

On 05/10/15 11:24, Laxman Dewangan wrote:


On Monday 21 September 2015 09:16 PM, Sudeep Holla wrote:


diff --git a/drivers/input/keyboard/tegra-kbc.c
b/drivers/input/keyboard/tegra-kbc.c
index f97c73bd14f8..5f5dbbd51991 100644
--- a/drivers/input/keyboard/tegra-kbc.c
+++ b/drivers/input/keyboard/tegra-kbc.c
@@ -705,7 +705,7 @@ static int tegra_kbc_probe(struct platform_device
*pdev)
  input_set_drvdata(kbc->idev, kbc);
  err = devm_request_irq(>dev, kbc->irq, tegra_kbc_isr,
-  IRQF_NO_SUSPEND | IRQF_TRIGGER_HIGH, pdev->name, kbc);
+   IRQF_TRIGGER_HIGH, pdev->name, kbc);



Acked-by: Laxman Dewangan 



Can you pick this up with all the Acks ?

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] HID: hiddev: change hiddev_connect() to return bool

[Krzysztof Kozlowski]

On 20.10.2015 00:11, Luis de Bethencourt wrote:
> On 13/10/15 02:49, Krzysztof Kozlowski wrote:
>> 2015-10-09 22:00 GMT+09:00 Luis de Bethencourt :
>>> Since hid_connect() only cares about hiddev_connect() succeeding or
>>> failing, there is no need for this function to return an int and it can
>>> return a bool instead.
>>
>> It can return bool but it would not be in line with kernel coding
>> style. The hiddev_connect() I believe is an action, so "the function
>> should return an error-code integer.".
>>
>> Best regards,
>> Krzysztof
>>
> 
> 
> Hi Krysztof,
> 
> The idea to switch the function to return bool was offered by Jiri Kosina,
> as a result of my initial patch changing the return errno code to ENOMEM.

I did not see the original comment from Jiri. Actually changing it to
ENOMEM makes more sense to me...

> 
> Considering the return isn't propagated by the only consumer of the function,
> and your point about returning an integer being the kernel coding style. It
> doesn't make sense to change this function.

Jiri is the maintainer here but for me sticking to coding convention
(return errno) makes it easier to read.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: ETPS/2 Elantech Touchpad dies after resume from suspend to RAM

[WangBiscuit]

Dear Mike Mestnik:
Thanks for you reply, but I really don't understand why a bug in gnome can make 
a hardware disappear from the kernel. Can you give me the link of the gnome bug 
report?

For more infomation, the directory /sys/devices/platform/i8042/serio1/input/ 
will totally disappeared in kernel 3.19 (In 4.3, the /proc/devices has changed 
into a file, not a directory) after resume from suspend.

--
From Biscuit Wang with outlook.com
Change your word, change your world.

-- Original --
From: "Mike Mestnik";;
Date: Mon, Oct 19, 2015 10:53 PM
To: "WBH";
Cc: "dmitry.torok...@gmail.com"; "linux-input@vger.kernel.org";
Subject: Re: PROBLEM: ETPS/2 Elantech Touchpad dies after resume from suspendto 
RAM

>Smells like a known issue with gnome, fixed in recent releases.
>
>On Sun, Oct 18, 2015 at 10:59 PM, WBH wrote:
>> [1.] One line summary of the problem:
>> ETPS/2 Elantech Touchpad dies after resume from suspend to RAM
>>
>> [2.] Full description of the problem/report:
>> When the system startup, the touchpad works well, but after it resumed from 
>> a suspend, the touchpad hardware will disappear from xinput and cat 
>> /proc/bus/input/devices.
>>
>> Before suspend, xinput output
>> ⎡ Virtual core pointer id=2 [master pointer (3)]
>> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
>> ⎜ ↳ USB OPTICAL MOUSE id=10 [slave pointer (2)]
>> ⎜ ↳ ETPS/2 Elantech Touchpad id=14 [slave pointer (2)]
>> ⎣ Virtual core keyboard id=3 [master keyboard (2)]
>> ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
>> ↳ Power Button id=6 [slave keyboard (3)]
>> ↳ Video Bus id=7 [slave keyboard (3)]
>> ↳ Video Bus id=8 [slave keyboard (3)]
>> ↳ Sleep Button id=9 [slave keyboard (3)]
>> ↳ USB2.0 VGA UVC WebCam id=11 [slave keyboard (3)]
>> ↳ Asus WMI hotkeys id=12 [slave keyboard (3)]
>> ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
>>
>> after suspend, the output
>> ⎡ Virtual core pointer id=2 [master pointer (3)]
>> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
>> ⎜ ↳ USB OPTICAL MOUSE id=10 [slave pointer (2)]
>> ⎣ Virtual core keyboard id=3 [master keyboard (2)]
>> ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
>> ↳ Power Button id=6 [slave keyboard (3)]
>> ↳ Video Bus id=7 [slave keyboard (3)]
>> ↳ Video Bus id=8 [slave keyboard (3)]
>> ↳ Sleep Button id=9 [slave keyboard (3)]
>> ↳ USB2.0 VGA UVC WebCam id=11 [slave keyboard (3)]
>> ↳ Asus WMI hotkeys id=12 [slave keyboard (3)]
>> ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
>> And you can find that the " ETPS/2 Elantech Touchpad" is missing
>> output of dmesg:
>> dmesg|grep mouse
>> [ 0.512423] mousedev: PS/2 mouse device common for all mice
>> [ 1.114531] psmouse serio1: elantech: assuming hardware version 4 (with 
>> firmware version 0x381f00)
>> [ 1.128082] psmouse serio1: elantech: Synaptics capabilities query result 
>> 0x10, 0x14, 0x0e.
>>
>> After a reboot, everything works well again.
>>
>> When I using s2disk with this conf file, the touchpad works well after 
>> resume. But if the "shutdown method" is set to platform, the hibernate 
>> process will hang after snapshotting the system.
>> # /etc/uswsusp.conf(5) -- Configuration file for s2disk/s2both
>> resume device = /dev/disk/by-uuid/7b13204e-719a-4ee4-a523-909e75b56507
>> compress = y
>> early writeout = y
>> image size = 0
>> RSA key file = /etc/uswsusp.key
>> shutdown method = shutdown
>> compute checksum = y
>> suspend loglevel = 1
>> max loglevel = 15
>>
>>
>> [3.] Keywords (i.e., modules, networking, kernel):
>> [4.] Kernel version (from /proc/version):
>> Linux version 4.3.0-040300rc5-generic (kernel@tangerine) (gcc version 4.8.4 
>> (Ubuntu 4.8.4-2ubuntu1~14.04) ) #201510111530 SMP Sun Oct 11 19:31:35 UTC 
>> 2015
>>
>> [5.] Output of Oops.. message (if applicable) with symbolic information
>> resolved (see Documentation/oops-tracing.txt)
>> [6.] A small shell script or example program which triggers the
>> problem (if possible)
>> $ sudo s2ram
>>
>> [7.] Environment
>> Description: Ubuntu 14.04.3 LTS
>> Release: 14.04
>>
>> [7.1.] Software (add the output of the ver_linux script here)
>> Linux biscuit 4.3.0-040300rc5-generic #201510111530 SMP Sun Oct 11 19:31:35 
>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Gnu C 4.8
>> Gnu make 3.81
>> binutils 2.24
>> util-linux 2.20.1
>> mount support
>> module-init-tools 15
>> e2fsprogs 1.42.9
>> pcmciautils 018
>> PPP 2.4.5
>> Linux C Library 2.19
>> Dynamic linker (ldd) 2.19
>> Procps 3.3.9
>> Net-tools 1.60
>> Kbd 1.15.5
>> Sh-utils 8.21
>> wireless-tools 30
>> Modules Loaded drbg ansi_cprng ctr ccm pci_stub vboxpci vboxnetadp 
>> vboxnetflt vboxdrv cmac rfcomm bnep binfmt_misc nls_iso8859_1 
>> snd_hda_codec_hdmi asus_nb_wmi asus_wmi mxm_wmi sparse_keymap 
>> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec 
>> snd_hda_core snd_hwdep snd_pcm uvcvideo videobuf2_vmalloc videobuf2_memops 
>> videobuf2_core intel_rapl v4l2_common 

Re: Regression since commit 92bac83

[Hans de Goede]

Hi,

On 19-10-15 18:51, Dmitry Torokhov wrote:

On Mon, Oct 19, 2015 at 10:55:20AM -0500, Larry Finger wrote:

On 10/19/2015 03:08 AM, Hans de Goede wrote:

Hi,

On 19-10-15 01:59, Larry Finger wrote:

Hi,

I recently upgraded the kernel in a Dell Latitude D600 and found that the
touchpad clicks failed. The problem was bisected to commit
92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
dualpoint has separate stick button bits"). The laptop has a combination
touchpad and control stick. For this device, the following values are found:

priv->protoversion is 0x200 (ALPS_PROTO_V2)
priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)

As a result, the new code added in this patch is executed, and left, right,
and middle are updated. Once this code is introduced, a left click causes some
event as it will wake a sleeping screen, but not select any windows or do
anything useful.

Please advise on what information would be needed to help debug this problem.


Can you build a recent upstream kernel from source, and when building it
comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 2556

 if (dmi_name_in_vendors("Dell"))
 priv->flags |= ALPS_DELL;

That should fix things, if that fixes things we need to rename the flag
and move to a list of dmi-matched models (rather then vendor) where the new
behavior
introduced by the patch causing you problems is actually necessary.

Step 1 is confirming that not setting the flag fixes things for you,
if you can get back to us confirming that, then I'll whip up a patch
to switch to model matching (which is not ideal, but seems to be
necessary).


Thanks for the quick response. Removing the two lines mentioned
above restored correct touchpad operation with kernel 4.2.0. It
seems that the Latitude D600 is different than other Dell models.


I wonder if we should not revert all these patches splitting what once
was one relative input device into separate trackstick/external mouse.
They seem to cause a lot of troubles for little benefit. Pali?


This is unrelated to this splitting, on v2 devices (which we are talking
about here) we always combine all button status, and report the buttons
on the device from which we are actually getting packets atm (only one
sends packets at a time on these specific laptops) and then do some
magic to make sure we send the release on the right device, this all
works well.

The problem is that when using the touchpad (so the touchpad and not
the stick is generating packets) combined with the trackpoint buttons,
the buttons get reported in a different place in the touchpad packet
then when using the touchpad buttons themselves, which is what
commit 92bac83 fixes.

AFAICT we've had the bug which commit 92bac83 fixes since more or less
day 1 of the alps driver, but no one noticed and/or reported the problem
since reproducing the problem is somewhat hard.

Another reason why this problem was likely not noticed until recently
is because it seems it affects only a limited number of models. At first
I thought it would affect all non-interleaved dualpoint v2 devices, then
when we got bug reports of commit 92bac83 causing issues for some non
Dell laptops, I added the DELL flag and limited the fix to only Dell
laptops, and now it seems the separate reporting of the trackpoint buttons
in the touchpad packets only happens on some model Dells.

TL;DR: this is not caused by Pali's patches, if you want to blame anyone
it would be me. In hindsight the fix commit 92bac83 introduces should
have been behind a quirk flag which is only set on specific models.

I will write a patch this week actually changing the fix to use such
a quirk flag.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression since commit 92bac83

[Dmitry Torokhov]

On Mon, Oct 19, 2015 at 10:55:20AM -0500, Larry Finger wrote:
> On 10/19/2015 03:08 AM, Hans de Goede wrote:
> >Hi,
> >
> >On 19-10-15 01:59, Larry Finger wrote:
> >>Hi,
> >>
> >>I recently upgraded the kernel in a Dell Latitude D600 and found that the
> >>touchpad clicks failed. The problem was bisected to commit
> >>92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
> >>dualpoint has separate stick button bits"). The laptop has a combination
> >>touchpad and control stick. For this device, the following values are found:
> >>
> >>priv->protoversion is 0x200 (ALPS_PROTO_V2)
> >>priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)
> >>
> >>As a result, the new code added in this patch is executed, and left, right,
> >>and middle are updated. Once this code is introduced, a left click causes 
> >>some
> >>event as it will wake a sleeping screen, but not select any windows or do
> >>anything useful.
> >>
> >>Please advise on what information would be needed to help debug this 
> >>problem.
> >
> >Can you build a recent upstream kernel from source, and when building it
> >comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 
> >2556
> >
> > if (dmi_name_in_vendors("Dell"))
> > priv->flags |= ALPS_DELL;
> >
> >That should fix things, if that fixes things we need to rename the flag
> >and move to a list of dmi-matched models (rather then vendor) where the new
> >behavior
> >introduced by the patch causing you problems is actually necessary.
> >
> >Step 1 is confirming that not setting the flag fixes things for you,
> >if you can get back to us confirming that, then I'll whip up a patch
> >to switch to model matching (which is not ideal, but seems to be
> >necessary).
> 
> Thanks for the quick response. Removing the two lines mentioned
> above restored correct touchpad operation with kernel 4.2.0. It
> seems that the Latitude D600 is different than other Dell models.

I wonder if we should not revert all these patches splitting what once
was one relative input device into separate trackstick/external mouse.
They seem to cause a lot of troubles for little benefit. Pali?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] xen: check return value of xenbus_printf

[Dmitry Torokhov]

On Mon, Oct 19, 2015 at 04:02:51PM +, Insu Yun wrote:
> Signed-off-by: Insu Yun 

Applied, thank you. However you still are missing the commit description
on this version of the patch; I had to fish it from your original
posting.

Thanks.

> ---
>  drivers/input/misc/xen-kbdfront.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 23d0549..0a9ad2cf 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -129,8 +129,14 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  
>   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
> ) < 0)
>   abs = 0;
> - if (abs)
> - xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", 
> "1");
> + if (abs) {
> + ret = xenbus_printf(XBT_NIL, dev->nodename,
> + "request-abs-pointer", "1");
> + if (ret) {
> + pr_warning("xenkbd: can't request abs-pointer");
> + abs = 0;
> + }
> + }
>  
>   /* keyboard */
>   kbd = input_allocate_device();
> -- 
> 1.9.1
> 

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html