Re: Logitech G27 leds no more supported

2018-10-23 Thread Simon Wood 
On Sun, October 21, 2018 10:43 am, elrond...@protonmail.com wrote:
> SOLVED that's due to this is compiled as modules:
> CONFIG_LEDS_SYSCON
> CONFIG_LEDS_SYSCON
>
>
> and not as YES option

I'm not seeing the connection between this being a module and breaking
(specifically) the Logitech driver. We're only checking
'CONFIG_LEDS_CLASS'.

Did you have 'CONFIG_LEDS_CLASS' compiled as a module as well?

I did a workaround for this in the SteelSeries driver...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-steelseries.c?h=v4.19#n20
--
#if IS_BUILTIN(CONFIG_LEDS_CLASS) || \
(IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES))
#define SRWS1_NUMBER_LEDS 15
struct steelseries_srws1_data {
__u16 led_state;
/* the last element is used for setting all leds simultaneously */
struct led_classdev *led[SRWS1_NUMBER_LEDS + 1];
};
#endif
--

Cheers,
Simon


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/Kconfig?h=v4.19
--
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
depends on MFD_SYSCON
depends on OF
help
  This option enables support for the LEDs on syscon type
  devices. This will only work with device tree enabled
  devices.
--

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/Kconfig?h=v4.19#n548
--
config LOGIWHEELS_FF
bool "Logitech wheels configuration and force feedback support"
depends on HID_LOGITECH
select INPUT_FF_MEMLESS
default LOGITECH_FF
help
  Say Y here if you want to enable force feedback and range setting(*)
  support for following Logitech wheels:
  - Logitech G25 (*)
  - Logitech G27 (*)
  - Logitech G29 (*)
  - Logitech Driving Force
  - Logitech Driving Force Pro (*)
  - Logitech Driving Force GT (*)
  - Logitech Driving Force EX/RX
  - Logitech Driving Force Wireless
  - Logitech Speed Force Wireless
  - Logitech MOMO Force
  - Logitech MOMO Racing Force
  - Logitech Formula Force GP
  - Logitech Formula Force EX/RX
  - Logitech Wingman Formula Force GP
--


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-lg4ff.c?h=v4.19#n1087
--
#ifdef CONFIG_LEDS_CLASS
static void lg4ff_set_leds(struct hid_device *hid, u8 leds)
{
--

Re: Logitech G27 leds no more supported

2018-10-19 Thread Simon Wood 
On Fri, October 19, 2018 4:46 pm, Simon Wood wrote:

> Thanks for the report, and yes it does seem broken. I tried on
> 4.17.0-rc5+
> and it seems that the 'hid-logitech' module does not know the device ID of
>  the G29 anymore.

Oh, how easily we forget things... there's a switch on the top wheel
(close to LEDs) which changes the wheel into a compatibility mode.

Flipping this get wheel recognized and working on 4.17.0-rc5+
--
root@thevoid:/sys/class/leds# ls
0003:046D:C24F.0009::RPM1  0003:046D:C24F.0009::RPM4  input3::numlock
input8::compose  input8::scrolllock
0003:046D:C24F.0009::RPM2  0003:046D:C24F.0009::RPM5  input3::scrolllock 
input8::kana
0003:046D:C24F.0009::RPM3  input3::capslock   input8::capslock   
input8::numlock
root@thevoid:/sys/class/leds# cd 0003\:046D\:C24F.0009\:\:RPM4
root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# ls
brightness  device  max_brightness  power  subsystem  trigger  uevent
root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# cat max_brightness
> brightness
--

I'll rebuild HEAD to confirm it still works.
Simon.

PS. We should maybe pick up that other USB Id.

Re: Logitech G27 leds no more supported

2018-10-19 Thread Simon Wood 
On Wed, October 17, 2018 11:21 pm, Greg KH wrote:
> On Wed, Oct 17, 2018 at 02:44:51PM +, elrond...@protonmail.com wrote:
>> No more leds subdirectory for this wheel, someone reports me G29 leds
>> stays supported correctly.
>>
>> No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds
>> are detected. Force feedback are correctly supported.
>>

> What kernel version did this work properly on?
>
>
> And I think the linux-input mailing list would want to know about this,
> this isn't a usb-core specific issue.  I've added them to the cc: here.
> thanks,

Thanks for the report, and yes it does seem broken. I tried on 4.17.0-rc5+
and it seems that the 'hid-logitech' module does not know the device ID of
the G29 anymore.

Support was originally added in 29fae1c85166ef525b8b6518e749295e0c9d1e20,
but that was a long time ago and it seems that the 'hid-core.c' stuff has
somewhat changed

Will continue looking for cause.
Simon
Syslog on insert
--
Oct 19 16:16:04 thevoid kernel: [33656.156644] usb 1-2: new full-speed USB 
device number 12 using xhci_hcd
Oct 19 16:16:05 thevoid kernel: [33656.306093] usb 1-2: New USB device found, 
idVendor=046d, idProduct=c260, bcdDevice=89.00
Oct 19 16:16:05 thevoid kernel: [33656.306106] usb 1-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Oct 19 16:16:05 thevoid kernel: [33656.306114] usb 1-2: Product: G29 Driving 
Force Racing Wheel
Oct 19 16:16:05 thevoid kernel: [33656.306122] usb 1-2: Manufacturer: Logitech
Oct 19 16:16:05 thevoid kernel: [33656.314487] input: Logitech G29 Driving 
Force Racing Wheel as 
/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006/input/input22
Oct 19 16:16:05 thevoid kernel: [33656.373288] hid-generic 0003:046D:C260.0006: 
input,hiddev3,hidraw5: USB HID v1.10 Joystick [Logitech G29 Driving Force 
Racing Wheel] on usb-:00:14.0-2/input0
Oct 19 16:16:05 thevoid mtp-probe: checking bus 1, device 12: 
"/sys/devices/pci:00/:00:14.0/usb1/1-2"
Oct 19 16:16:05 thevoid mtp-probe: bus: 1, device: 12 was not an MTP device
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2
--

lsusb -vv
--
Bus 001 Device 012: ID 046d:c260 Logitech, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x046d Logitech, Inc.
  idProduct  0xc260 
  bcdDevice   89.00
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   41
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  200mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 160
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
--

uname -a
--
Linux thevoid 4.17.0-rc5+ #11 SMP Sat May 19 11:08:23 MDT 2018 x86_64 x86_64 
x86_64 GNU/Linux
--
filename:   /lib/modules/4.17.0-rc5+/kernel/drivers/hid/hid-logitech.ko
license:GPL
srcversion: D51DE1425C46A412C85BBE4
alias:

Re: Tascam US-122L - Corrupt USB descriptor

2016-04-14 Thread Simon Wood 
On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
> Simon Wood wrote:
>
>> The card shows up under '/proc/asound/cards', but only as Midi.
>>
>
> Apparently, there is no PCM device. This driver creates a special
> hardware-dependent device which is intended to be used with the Jack driver
> "usb_stream".
>
>
> It might be possible to use the ALSA "usb_stream" plugin:
> <http://www.alsa-project.org/main/index.php/Matrix:Module-usb-us122l>

I have this '.asoundrc' file (made before previous postings), but that
does not seem to make a usable card.

I'm expecting that a PCM device should /just/ appear under 'aplay -l', but
that is not happening. Perhaps there is a step I am missing, or I am just
confused about what qualifies a 'working' US-122L.

Do I need to be using a specific version of (userland) Alsa?

It would be nice to get a 'nod' from a person who has the US-122L workin
on their system. But I do appreciate Clemens' help and guidance,
Simon.

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

Re: Tascam US-122L - Corrupt USB descriptor

2016-04-13 Thread Simon Wood 
On Wed, April 13, 2016 3:01 am, Clemens Ladisch wrote:
> Simon Wood wrote:
>
>> I have been struggling for the past few days to get a Tascam US-122L
>> (USB
>> sound-card/midi interface) working, despite reading numerous forum
>> postings I have only been able to get the midi portion working.
>
> Does it show up with "aplay -l"?

The card shows up under '/proc/asound/cards', but only as Midi. See
attached for full listing.


>> I note that the USB descriptor seems to be corrupt. It declares 2
>> interfaces, but then describes 3 separate with the same interface number
>>  for the last 2.
>
> The descriptors describe two alternate settings for the same interface.
> This is a feature, which is required for audio devices.
>
>
>> iManufacturer   1 (error)<-- Here be 
>> Errors! iProduct
>> 2 (error)
>> iSerial 3 (error)
>
> It's possible that lsusb does not have the permissions needed to send
> the messages to ask for the strings.  Try running it as root.

Was running as root (on Xubuntu, 2 different machines, different installs).

I note that sometimes this is OK, ie when I do '# echo 0 >
/sys/bus/usb/devices/1-2/bConfigurationValue', but then I have no
interfaces at all (no midi, no listing).

Can anyone confirm they have a US-122L working on a new kernel. Is the USB
descriptor the same as what I'm seeing, perhaps hardware changed at some
point.
Cheers,
Simon# cat /proc/asound/cards  > aplay_l.txt
 0 [Audigy2]: Audigy2 - SB Audigy 2 ZS [SB0350]
  SB Audigy 2 ZS [SB0350] (rev.4, serial:0x20021102) at 
0xccc0, irq 27
 1 [US122L ]: USB US-122L - TASCAM US-122L
  TASCAM US-122L (644:800e if 0 at 001/005)

# aplaymidi -l >> aplay_l.txt
 PortClient name  Port name
 14:0Midi Through Midi Through Port-0
 16:0SB Audigy 2 ZS [SB0350]  Audigy MPU-401 (UART)
 16:32   SB Audigy 2 ZS [SB0350]  Audigy MPU-401 #2
 17:0Emu10k1 WaveTableEmu10k1 Port 0
 17:1Emu10k1 WaveTableEmu10k1 Port 1
 17:2Emu10k1 WaveTableEmu10k1 Port 2
 17:3Emu10k1 WaveTableEmu10k1 Port 3
 20:0TASCAM US-122L   TASCAM US-122L MIDI 1

# aplay -l >> aplay_l.txt
 List of PLAYBACK Hardware Devices 
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 0: emu10k1 [ADC 
Capture/Standard PCM Playback]
  Subdevices: 32/32
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
  Subdevice #8: subdevice #8
  Subdevice #9: subdevice #9
  Subdevice #10: subdevice #10
  Subdevice #11: subdevice #11
  Subdevice #12: subdevice #12
  Subdevice #13: subdevice #13
  Subdevice #14: subdevice #14
  Subdevice #15: subdevice #15
  Subdevice #16: subdevice #16
  Subdevice #17: subdevice #17
  Subdevice #18: subdevice #18
  Subdevice #19: subdevice #19
  Subdevice #20: subdevice #20
  Subdevice #21: subdevice #21
  Subdevice #22: subdevice #22
  Subdevice #23: subdevice #23
  Subdevice #24: subdevice #24
  Subdevice #25: subdevice #25
  Subdevice #26: subdevice #26
  Subdevice #27: subdevice #27
  Subdevice #28: subdevice #28
  Subdevice #29: subdevice #29
  Subdevice #30: subdevice #30
  Subdevice #31: subdevice #31
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 2: emu10k1 efx [Multichannel 
Capture/PT Playback]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 3: emu10k1 [Multichannel 
Playback]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 4: p16v [p16v]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Tascam US-122L - Corrupt USB descriptor

2016-04-13 Thread Simon Wood 
Hi all,
I have been struggling for the past few days to get a Tascam US-122L (USB
sound-card/midi interface) working, despite reading numerous forum
postings I have only been able to get the midi portion working.

I note that the USB descriptor seems to be corrupt. It declares 2
interfaces, but then describes 3 separate with the same interface number
for the last 2... could it be that this is confusing the Linux USB stack?

I have attached a copy of the descriptor and an annotated 'lsusb -vv'.


>From my experience with the HID subsystem, they have a mechanism for
patching HID descriptors, is the same possible for the base USB
descriptor? Trolling through 'drivers/usb' I didn't see anything... any
suggestions?

If this is possible I can try to increase the interface count and renumber
the last one.

Cheers,
Simon.

PS. For reference the device is:
Model No: US-122L
Serial: (21)0120xxx
Other barcode: 043774021628  12 01 00 02 00 00 00 40  44 06 0e 80 00 01 01 02  |...@D...|
0010  03 01 09 02 48 00 02 01  00 80 f0 09 04 00 00 00  |H...|
0020  ff 00 00 00 09 04 01 00  00 ff 00 00 00 09 04 01  ||
0030  01 04 ff 00 00 00 09 05  81 05 4e 00 01 00 00 09  |..N.|
0040  05 02 05 4e 00 01 00 00  09 05 83 02 09 00 04 00  |...N|
0050  00 09 05 04 02 00 02 04  00 00|..|
005a



Bus 001 Device 042: ID 0644:800e TEAC Corp. TASCAM US-122L
--
  12 01 00 02 00 00 00 40  44 06 0e 80 00 01 01 02  |...@D...|
0010  03 01 __  |H...|
--
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0644 TEAC Corp.
  idProduct  0x800e TASCAM US-122L
  bcdDevice1.00
  iManufacturer   1 (error) <-- Here be 
Errors!
  iProduct2 (error)
  iSerial 3 (error)
  bNumConfigurations  1

  Configuration Descriptor:
--
0010  _ 09 02 48 00 02 01  00 80 f0 __  |H...|
--
bLength 9
bDescriptorType 2
wTotalLength   72
bNumInterfaces  2   <--- 2 
interfaces
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  480mA


Interface Descriptor:   <-- that's 1
--
0010  _ 09 04 00 00 00  |H...|
0020  ff 00 00 00   ||
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

Interface Descriptor:   <-- that's 2
--
0020  ___ 09 04 01 00  00 ff 00 00 00   ||
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

Interface Descriptor:   <-- that's 
3, err wait...
--
0020  ___ 09 04 01  ||
0030  01 04 ff 00 00 00 __  |..N.|
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1 <-- 
interface duplicate!!
  bAlternateSetting   1
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

  Endpoint Descriptor:
--
0030  _ 09 05  81 05 4e 00 01 00 00 __  |..N.|
--
bLength 9
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes5
  Transfer TypeIsochronous
  Synch Type   Asynchronous
  Usage Type   Data
wMaxPacketSize 0x004e  1x 78 bytes
bInterval   1
bRefresh0
bSynchAddress   0

  Endpoint Descriptor:
--
0030  _ 09  |..N.|
0040  05 02 05 4e 00 01 00 00  ___