gmane.linux.kernel.input

(unknown)

robothroli company — 2012-05-25T13:45:54

 i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:

Sample availability and price
Minimum order quantity
FOB Prices

Sincerely
Purchase Manager
robothroli



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

[PATCH 05/15] keyboard: imx_keypad: Use clk_prepare_enable/clk_disable_unprepare

Fabio Estevam — 2012-05-25T23:14:46

From: Fabio Estevam <fabio.estevam< at >freescale.com>

Prepare the clock before enabling it.

Cc: Dmitry Torokhov <dmitry.torokhov< at >gmail.com>
Cc: <linux-input< at >vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam< at >freescale.com>
---
 drivers/input/keyboard/imx_keypad.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
index 6ee7421..9d57945 100644
--- a/drivers/input/keyboard/imx_keypad.c
+++ b/drivers/input/keyboard/imx_keypad.c
< at >< at > -378,7 +378,7 < at >< at > static void imx_keypad_close(struct input_dev *dev)
 imx_keypad_inhibit(keypad);
 
 /* Disable clock unit */
-clk_disable(keypad->clk);
+clk_disable_unprepare(keypad->clk);
 }
 
 static int imx_keypad_open(struct input_dev *dev)
< at >< at > -391,7 +391,7 < at >< at > static int imx_keypad_open(struct input_dev *dev)
 keypad->enabled = true;
 
 /* Enable the kpp clock */
-clk_enable(keypad->clk);
+clk_prepare_enable(keypad->clk);
 imx_keypad_config(keypad);
 
 /* Sanit

HID Output and Feature Reports

Joao Paulo Rechi Vita — 2012-05-25T20:51:28

Hello all,

I'm working to support HID over GATT (HoG), which is HID over
Bluetooth Low Energy links, both on kernel and userspace. Traffic
coming from the remote peripheral through a L2CAP socket will be
handled in usespace, where the HID input reports are decapsulated from
GATT and injected back into the kernel through the new uHID module
written by David Herrmann. This module works similar to uinput, but
dealing with HID traffic.

The input part is working without problems and now I looking how to
support Output and Feature reports. Doing some basic testing it seems
we don't support Output reports very well. A basic use-case for that
is synchronizing keyboard leds (CAPS, NUM, etc) when there is more
than one keyboard connected, and I couldn't get this to work on my
tests. I didn't try to test feature reports since it's still not very
clear to me when they're used. The HID spec says that they exist for
setting values/controls on the peripheral that are not visible to the
user, but I haven't discovered any

Re: [git pull] Input updates for 3.5-rc0

Mark Lord — 2012-05-25T19:05:00

I regularly work with input devices from userspace,
using the "lsinput" "xinput", and "input-kbd" commands (among others)
from various shell scripts.

So I guess that makes me one of those anonymous "nobody" types
who "don't care" about it.

Usually the device naming I see there makes some kind of sense.

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

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T22:05:09

On Thu, May 24, 2012 at 3:01 PM, Greg Kroah-Hartman
<gregkh< at >linuxfoundation.org> wrote:

A full sysfs path really looks pretty ugly, partly because we'd have
to really change all our naming (look at PCI devices now: they end up
looking like

    pci0000:00/0000:00:1a.0

where that "0000:00" is duplicated because we wanted to make
dev_name() look nice).

I think Dmitry's idea to stop when we hit the actual "physical" device
might just work in practice. So we'd show the dev_name() of the actual
piece of hardware, and then perhaps one or two "layering" details on
top of it. And it wouldn't change anything for the current common case
where people tend to pass in the physical device as-is.

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

Re: [git pull] Input updates for 3.5-rc0

Greg Kroah-Hartman — 2012-05-24T22:01:05

I'm open to ideas on what to change it to.  A full sysfs path?
Something more "unique"?  I don't know what works for everything here.

thanks,

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

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T21:59:21

On Thu, May 24, 2012 at 2:56 PM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:

That really sounds quite nice. It would make sense to show both the
actual device information, and the "software layer" on top of it.

Except maybe it then would be absolutely disgusting for some other
case. Hmm. I really can't think of any bad situation off-hand, though.

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

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T21:44:31

On Thu, May 24, 2012 at 2:07 PM, Linus Torvalds
<torvalds< at >linux-foundation.org> wrote:

Ok, so I wonder if we could solve the issue at least partly by
separating the "print name for kernel messages" from the "name used
for /sysfs etc".

Because you're right: the sysfs uniqueness rules does make it very
hard to do a good job on descriptive names.

Also, in sysfs, you by definition see the parent (hey, it's part of
the path), so in sysfs, duplicating parent data would be useless and
just ugly.

But for dev_dbg(), those sysfs rules actually act against us: the name
of a device is often tied to the parent bus location.

So I wonder if we could teach  dev_printk() to use something more
interesting than "dev_name()" when appropriate? Greg?

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

Re: [git pull] Input updates for 3.5-rc0

Dmitry Torokhov — 2012-05-24T21:38:13

I can see the desire for logging, it is just hard to come with good
automatic way of doing this without burdening drivers, given that errors
happen rarely in input core layer and in driver code we already have
perfect device object to report against.

Maybe dev_XXX() should report full sysfs path do the dveice? Still does
not help with the fact that "driver" shown for class devices is not so
interesting as it will always be the class name.

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T21:07:29

On Thu, May 24, 2012 at 1:59 PM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:

Ok, that's certainly a valid concern.

It's still - I think - really sad/wrong that the device name is then
so useless than the drivers end up basically not using it.

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

Re: [git pull] Input updates for 3.5-rc0

Dmitry Torokhov — 2012-05-24T20:59:52

I was concerned about the _next_ device (the one that will be created
the moment I plug in the tablet back into the same port) having exact
same name as the one that is half dead and clashing in sysfs and
elsewhere. We used to have issues with this.


and it guarantees to make the name unique, that is all we need.

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T20:48:57

On Thu, May 24, 2012 at 1:36 PM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:

No, that wasn't the silly part of your statement.

The silly part is that

  dev_set_name(&dev->dev, "input-%s", dev_name(dev->dev.parent));

works perfectly fine if the parent goes away, for a damn simple
reason: it generates the string *once*, and doesn't care one *whit*
about the parent pointer ever again afterwards.

For exactly the same that your current

  dev_set_name(&dev->dev, "input%d", atomic_inc_return(&input_no) - 1);

doesn't care *at*all* about that "input_no" variable afterwards -
dev_set_name() will have turned it into a string, and "input_no" can
change as much as it wants, and that won't change the name of the
device.

See? So no "refcounting parents" or "zombie devices" or any crap like
that. The name is just a string.

Anyway, I can't be bothered to argue. If you think "input1" is such a
great name, and then that results in nobody actually ever *using* it
because everybody agrees it useless and will use

Re: [git pull] Input updates for 3.5-rc0

Dmitry Torokhov — 2012-05-24T20:36:47

Hmm, I guess we are better now with cleaning and turning devices into
zombies waiting to be reaped. Still have to handle parent have several
input devices (HID devices quite often do it). And I still do not see
the point why we want to bother, the proper layer to report driver
errors is driver and object it is bound to.

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T20:11:14

On Thu, May 24, 2012 at 12:58 PM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:

I'll let you think about just how stupid that comment was for a moment.

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

Re: [git pull] Input updates for 3.5-rc0

Linus Torvalds — 2012-05-24T18:21:20

On Thu, May 24, 2012 at 11:01 AM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:

*NEITHER* of your points actually address my issue.

If the "inputX" name is useless (and dammit, I agree), then why do you
continue to use it then?

IOW, why the hell do you set a name that is so useful that no sane
person would ever want to use it?

Basically, my complaint is that the input layer drivers end up doing
stupid things ("dev_dbg(input->dev.parent..") because the input layer
has done stupid things (dev_set_name(&dev->dev, "input%ld").

So let me be more blunt and direct: which part of "that's f*cking
stupid" do you disagree with?

So instead of making drivers do stupid things because you've made the
input layer names so damn useless, why don't you make the input layer
use better naming? Doesn't that seem to be the *smart* thing to do?

Wouldn't everybody be much happier if they saw useful names in the
device tree? And then the drivers could actually *use* those useful
names, instead of clearly saying "our names

Re: [git pull] Input updates for 3.5-rc0

Dmitry Torokhov — 2012-05-24T18:01:54

A couple of points:

1. A driver should try to use the same device for all its messages and
input devices are not created yet at the time we try to bind USB
interface to a driver. Most (all?) USB probe() methods use interface's
device with dev_xxx() which shows exactly which interface we are dealing
with.

2. Input devices are essentially driver-less (they are class devices) and
therefore do not provide useful information if used in messages as the
format of the message would be:

input inputX: some message

which does not identify neitehr the driver nor hardware device.  By
using input->dev.parent we get to the USB interface thus getting more
meaningful messages:

wacom 2-1.2:1.0: some error happened

We had a discussion with Greg about this and he was going to change his
patchset to use USB interfaces in the messages...

Thanks.

RE: about input/hid

Pandruvada, Srinivas — 2012-05-24T15:16:37

I think it should be independent of USB and should be part of hid-core.c.
There is a possibility that HID over I2C, proprietary specs used by Win8 can be a standard in future.

Thanks,
Srinivas


-----Original Message-----
From: linux-input-owner< at >vger.kernel.org [mailto:linux-input-owner< at >vger.kernel.org] On Behalf Of loody
Sent: Thursday, May 24, 2012 6:39 AM
To: linux-input< at >vger.kernel.org; linux-usb< at >vger.kernel.org
Subject: about input/hid

hi all:
I have some questions about input/hid devices.
1. it seems only usb hid has reports_desc, why don't we put hid parse in usbhid/hid-core.c instead of hid/hid-core.c?
2. at the end of mail is the report from mouse hid.
    i. where is the "USAGE_PAGE (Button) " defined, I cannot find Button id in usage table.
    ii. REPORT_SIZE (1) always mean the unit is bit?
3. Spec seems only describe the value of the item mean, where I can find the rules of the layout of the descriptor?

char ReportDescriptor[50] = {
02     0x05, 0x01,                    // USAGE_PAGE (Generi

about input/hid

loody — 2012-05-24T13:38:51

hi all:
I have some questions about input/hid devices.
1. it seems only usb hid has reports_desc, why don't we put hid parse
in usbhid/hid-core.c instead of hid/hid-core.c?
2. at the end of mail is the report from mouse hid.
    i. where is the "USAGE_PAGE (Button) " defined, I cannot find
Button id in usage table.
    ii. REPORT_SIZE (1) always mean the unit is bit?
3. Spec seems only describe the value of the item mean, where I can
find the rules of the layout of the descriptor?

char ReportDescriptor[50] = {
02     0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
03     0x09, 0x02,                    // USAGE (Mouse)
04     0xa1, 0x01,                    // COLLECTION (Application)
05     0x09, 0x01,                    //   USAGE (Pointer)
06     0xa1, 0x00,                    //   COLLECTION (Physical)
07     0x05, 0x09,                    //     USAGE_PAGE (Button)
08     0x19, 0x01,                    //     USAGE_MINIMUM (Button 1)
09     0x29, 0x03,                    //     USAGE_MAXIM

Re: Reg. kernel crash while using pixcir touchscreen driver

Sachin Kamat — 2012-05-24T10:05:52

Yes, you are right. The platform data was getting freed after the binding.
It now works fine. Thanks for your help.

Re: [PATCH 5/7] input/nomadik-ske: move key scanning to delayed work

Linus Walleij — 2012-05-24T09:50:36

On Wed, May 16, 2012 at 8:33 PM, Dmitry Torokhov
<dmitry.torokhov< at >gmail.com> wrote:


I'll try to hunt down the reason for this, could you apply patches
1 thru 4 in the meantime, and we put 5-7 on hold? They are not
dependent in any way.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git pull] Input updates for 3.5-rc0

Dmitry Torokhov — 2012-05-24T08:32:16

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get:

- a bunch of new drivers (DA9052/53 touchscreenn controller, Synaptics
  Navpoint, LM8333 keypads, Wacom I2C touhscreen);
- updates to existing touchpad drivers (ALPS, Sntelic);
- Wacom driver now supports Intuos5;
- device-tree bindings in numerous drivers;
- other cleanups and fixes.

You will get a conflict in wacom_wac.c; please resolve taking "my"
chunks or let me know and I'll merge on my side.

Thanks!


Changelog:
---------

Ashish Jangam (1):
      Input: add support for DA9052/53 touch screen controller

Axel Lin (5):
      Input: serio - add helper macro for serio_driver boilerplate
      Input: serio - use module_serio_driver
      Input: gameport - add helper macro for gameport_driver boilerplate
      Input: gameport - use module_gameport_driver
      Input: use module_pci_driver

Daniel Kurtz (5):
      Input: atmel_mxt_ts - use CONFI