Alan Stern wrote:
> the device's embedded hub ACKs the packets from the PC and not the
> packets from the RPi.
>
> What other differences could there be? Timing? Power levels?
Yes, both good candidates. Can you measure VUSB? As for timing, the
host controller will send SOF more or less
Steinar H. Gunderson wrote:
> > Our interface for zero copy reads/writes is O_DIRECT, and that requires
> > not special memory allocation, just proper alignment.
>
> But that assumes you are using I/O using read()/write(). There's no way you
> can shoehorn USB isochronous reads into the read()
Markus Rechberger wrote:
> just improve that sloppy situation
Dude I don't care who you are, your attitude sucks, and flushes any
merit you have down the drain. It makes you look super bad. :)
> we're at 3 months now
Right, so chill out, watch a movie, go to a party, go to several,
have some
Jose Colmenares wrote:
> 128000 bytes per second for a 1000Hz frequency (which the device
> can give). 128000 bytes per second is a lot less than the 480 Mbps
> that USB 2 gives. That's what's killing me.
I don't think you have written that you have a particular latency
requirement, but Greg
Hi Enrico,
Enrico Mioso wrote:
> In case I am able, I'll provide more hints.
There are a few ways to get the kernel oops output off the computer
without copying off the screen; netconsole, a USB debug device, and
last but not least photographing the computer screen.
One problem with using a USB
Alan Stern wrote:
> > > > It does print out a message, though not a big one. Would you like it
> > > > to do something more specific? A more verbose "usage" message,
> > > > perhaps?
> > >
> > > That's a good idea, and additionally I think it would be important to
> > > print (much) more
Alan Stern wrote:
> It does print out a message, though not a big one. Would you like it
> to do something more specific? A more verbose "usage" message,
> perhaps?
That's a good idea, and additionally I think it would be important to
print (much) more information if the ioctl() fails.
> For
Patrick Shirkey wrote:
> > if the kernel does have support for xHCI, we assume that
> > the user will prefer xHCI over EHCI if the motherboard has xHCI.
>
> Obviously the solution above should suffice for my purposes but out
> of interest is it viable to make the switch accessible to run time
>
Patrick Shirkey wrote:
> I have read various forum posts and some of the archive from this list
> about the following error message:
>
> Not enough host controller resources for new device state
>
> Some people have had success with disabling XHCI at the BIOS level.
>
> That seems to be an
Patrick Shirkey wrote:
> > You essentially have to educate yourself on silicon level (ie. what
> > hardware IP is being used in which consumer products) to sustain a
> > dependency on 127 possible devices per bus.
> >
> > I guess you'll find that there are only very few xHCI IPs out there,
> >
Alan Stern wrote:
> if we can directly map the user-provided buffer for DMA.
Given a memory buffer either kernel or userspace has to apply the
hardware constraints to find out what part if any is usable for DMA.
I think it's fine to push this task to userspace - as long as
userspace has a way to
Jose Colmenares wrote:
> If the computer starts, and the IMU is already plugged in, I have
> to unplug it and plug it again. This is unacceptable because the
> IMU will be used in a robot, so we cannot just unplug it every time
> the robot starts.
In a prototype you could work around this problem
Krzysztof Opasiak wrote:
>> There's still a bit of a race condition here, isn't there?
>>
>> Is there any good way to deal with that?
>>
>> Yes, there is a race condition. If the program closes the device node
>> before the device is plugged in again, the ttyUSB number won't change;
Greg KH wrote:
> Userspace still has the port open, so the number is not reused until
> userspace closes the device node. Fix your userspace programs to
> properly listen to the hangup signal to know to release the device node
> and you should be fine.
There's still a bit of a race condition
Hello,
Bin Liu wrote:
> >> >There's still a bit of a race condition here, isn't there?
> >> >
> >> >Is there any good way to deal with that?
> >>
> >> What race condition are you seeing here?
> >
> > USB cable is unplugged
>
> Assuming /dev/ttyUSB0 is opened by process ATM.
>
> > Process is
Greg K-H wrote:
> >> Userspace still has the port open, so the number is not reused until
> >> userspace closes the device node. Fix your userspace programs to
> >> properly listen to the hangup signal to know to release the device
> >node
> >> and you should be fine.
> >
> >There's still a bit
Mathias Nyman wrote:
> it's possible that the failing "0" returned by xhci_alloc_dev() is
> not properly propageated/translated through usb core, the used usb
> libarary and whatever other userspace components on top.
Does any userspace API receive notification of this failure?
I don't think so.
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
>
Roland,
Roland Weber wrote:
> Assuming that this kernel does freeze, I will start to 'bisect' the
> differences in the kernel configurations
Thank you very much for doing this work. You are one of the many
open source heroes and heroines.
//Peter
--
To unsubscribe from this list: send the line
Johan Hovold wrote:
I started in the morning to build the driver from the source provided
by the vendor, but it was written in the times of kernel-version 2.4,
and I got hopelessly stuck.
The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
Johan Hovold wrote:
On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
..
garbage characters transmitted from embedded-device
..
It seems that there is some issue with the driver.
Why do think it's a driver issue?
I can confirm similar issues with the in-tree driver and my
Greg KH wrote:
int fd = open(/dev/ttyGS0, O_RDWR | O_NONBLOCK);
This line discipline is very different from the traditional tty
line discipline
..
this is a character device, with a very specific line discipline
that works in a very specific way and assumes you know exactly how
Sven Brauch wrote:
I don't make any other changes to the default settings. To be honest,
I'm not sure in which mode it is operating then (I was assuming raw, but
I might be wrong?).
You should explicitly set a mode if you need a particular mode,
otherwise the port might be in another mode.
Mathias Nyman wrote:
+++ b/drivers/usb/host/xhci-ring.c
@@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
return 0;
/* offset in TRBs */
segment_offset = trb - seg-trbs;
- if (segment_offset TRBS_PER_SEGMENT)
+ if
Stefan Agner wrote:
libftdi requires to detach the kernel driver to get access to the device
Control transfers ought to be possible without a detach.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
Joe wrote:
I'm considering the idea of posting without that tag for now,
so that you can evaluate/add my patch as soon as possible.
However... will it be possible, in case, to correct my previous
subbmitted patch to add the Suggested-by tag?
No, that's not possible. Once a commit has been
Felipe Balbi wrote:
On Mon, Apr 27, 2015 at 10:57:24AM +0530, Anjana V Kumar wrote:
But we see that the serial gadget driver does not set req-zero. But
others like u_ether and f_massstorage are setting the same.
Is there any specific reason why this is not done in gadget serial ?
Juergen Gross wrote:
Do you have another feeling about the probability of a need to do usb 3?
If it is already on the horizon I wouldn't want to do the user space
backend now and the kernel one next year. :-)
One year is pretty long in kernel time.
//Peter
--
To unsubscribe from this list:
Hello Joao,
Joao Pinto wrote:
This new feature basically is to turn the relationship between driver
and hardware IP more transparent, making the software more robust.
This is an important matter already today, and will only become more
important in the future.
a) The hardware has the
temp sha wrote:
Look closely in the kernel output and you'll see that no ids change,
but that the old device has disconnected and a new device has
connected.
sorry I could not get it completely.
what is this new device/ old device ?
A USB device as seen by the kernel is a software
temp sha wrote:
Yes running usb_modeswitch manually works, but once mode switch is
done product id is getting changed from 0x1446 to 0x1506.
Look closely in the kernel output and you'll see that no ids change,
but that the old device has disconnected and a new device has
connected.
looking
Dave Mielke wrote:
Under what circumstances should usbfs code, after having received a signal,
expect to not be able to reap a URB, and how should it interpret this
situation?
I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, urb) to either
return -1 with errno = ENODEV, or to return 0
Dave Mielke wrote:
[quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, urb) to either
return -1 with errno = ENODEV, or to return 0 with urb-status = ESHUTDOWN.
I just reverified. It's definitely returning -1 with EAGAIN
Bin Liu wrote:
I have a ARM SoC which has a dwc3 drd controller, to validate if there
is a limit of max device connections, I connected multiple hubs, then
keyboards and mice.
When plugged in the 32th device, xHCI shows the following message and
the numeration failed.
Not enough
Greg KH wrote:
I've found that screen can leave usb serial ports in an odd state,
it's not unique to this specific device, I blame the screen command :)
I think that's a lame excuse to not investigate a potential bug. It
would obviously be helpful if someone who experienced this
Greg KH wrote:
Is that some kind of initialization protocol I have to handle? If yes,
where do I find information about it?
The protocol should be part of the USB specification.
USB debug class devices use no protocol, just transfers of 1-8 bytes,
used in arbitrary ways by the various
Mark Glover wrote:
From: Mark Glover m...@actisense.com
Signed-off-by: Mark Glover m...@actisense.com
There's an extraneous leading whitespace on the Signed-off-by line.
+#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */
The typo remains. Apadter here
Please update your commit message to leave one blank line between the
commit message summary and the rest of the message. (This avoids your
signed-off-by ending up in the email subject.)
Mark Glover wrote:
+++ b/drivers/usb/serial/ftdi_sio_ids.h
..
+#define CHETCO_SEAGAUGE_PID 0xA548
Hi Ivo,
ivo welch wrote:
thank you, greg. if linux-usb is the wrong starter, can you
recommend some pointers to good starter documentation and books about
writing user-space USB programs? (is it really read the linux kernel
source??)
I've held a workshop on how to make your own USB device
Linus Torvalds wrote:
I seem to get this problem possibly more commonly at boot these days:
usb 1-6: device descriptor read/64, error -71
xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22
Since my upgrade to 98e8d2e0
Felipe Balbi wrote:
A babble only occurs when
the device side tries to move data without the host asking for anything.
It also occurs if the device moves more than packet_size bytes. Not
really helping, I know…
hmm, why would the device move more than wMaxPacketSize at a time ?
Breton M. Saunders wrote:
Are zero length transfers from a device to the PC on a bulk endpoint
sensible?
I don't see how they could be.
If the device has no data to send it responds with a NAK handshake.
If the device has data to send it responds with the data.
//Peter
--
To unsubscribe
Oliver Neukum wrote:
Then I guess I'll take no further action in kernel space.
I for one would like the kernel messages to be less prominent, if
they stay at all.
Since descriptors are not always correct, it's not so useful for the
kernel to output such loud messages.
//Peter
--
To
Moritz wrote:
With a recent Update from Kernel 3.16.14-1-x86_64 to
linux-3.17.1-1-x86_64 my machine isn't able anymore to recognise my TI
Tiva Lauchpad.
lsusb normally has the following entry:
Bus 004 Device 010: ID 1cbe:00fd Luminary Micro Inc. In-Circuit Debug
Interface
It vanishes with
Gene,
Gene Heskett wrote:
I think the point they were trying to make is that the device packager,
who may not be the chip vendor, can put, if there is room in its flashrom,
a short commend that would, on plugging it in, cause the machine to
silently go out on the net and become part of a
Gene Heskett wrote:
There is no paywall for USB specs.
I last looked about a year ago. The only link google could find
You should look on usb.org under Developer Documentation instead of
on google.com.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the
Anjana V Kumar wrote:
I am using 3.10 kernel. The issue is that the set_configuration(2)
is stalled, while the set_configuration(1) passes with the USB
hardware I am using.
What USB hardware are you using?
Why not look into the actual problem with SET_CONFIGURATION? You may
discover things
Hi,
Your kernel is ancient. You should either ask your kernel supplier
for support or switch to using a current upstream kernel if you want
help here.
I can just give some general libusb advice.
Pedro Erencia wrote:
we are having a curious behaviour with the USB OTG throughput on a
DM3730.
Pedro Erencia wrote:
Unfortunately we cannot change the linux kernel, we are tied to the
BSP supplied. :(
Then unfortunately you cannot get any help from the community, but
are tied also to the BSP supplier for your support. :(
We are currently doing synchronous bulk transfers but we also
Eric Smith wrote:
could use some advice on how I might go about debugging the problem
if it is in the ftdi_sio driver.
As a data point you could compare the userspace approach with libftdi1.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
Hi Niyazi,
Niyazi Sırt wrote:
I had kernel-3.4.52, libusb-0.1.12 and usbutils-0.71
on my centos and lsusb command was working properly.
After I upgraded kernel-3.14.9 and also upgraded
libusb-static-1.0.9, libusb-1.0.9, libusb-devel-1.0.9
and usbutils-006 rpm packages, lsusb command stopped
Raghavendra wrote:
I have a query regarding DMA(Direct Memory Access) for the usb devices.
USB devices never do DMA.
As far as Linux is concerned, how the DMA action being taking place for
USB devices.
It doesn't take place.
As per my understanding, the USB host controller is taking care
Andrzej Pietrasiewicz wrote:
+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {
..
+/* MS OS Extended Compatibility Descriptor header */
+struct usb_ext_compat_desc_header {
+ struct usb_os_desc_header header;
+ __u8bCount;
+
Thank you very much for working on this, Stefan.
Alan Stern wrote:
Also, many host controllers cannot handle arbitrary alignment.
It would be best to require that the buffer start at a page boundary.
This requires a bit of negotiation with userspace, maybe per-URB but
it seems better to
Alan Stern wrote:
Also, many host controllers cannot handle arbitrary alignment.
It would be best to require that the buffer start at a page boundary.
This requires a bit of negotiation with userspace, maybe per-URB but
I don't follow. What negotiation is needed? All that needs
Philipp Hachtmann wrote:
This patch adds a sysfs attribute cbus which allows to set the
four CBUS pins on the FT232H.
I think this should be implemented with the gpio subsystem instead.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
Bjørn Mork wrote:
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -0,0 +1,143 @@
+What:/sys/class/net/iface/cdc_ncm/min_tx_pkt
+Date:May 2014
+KernelVersion: 3.16
+Contact: Bjørn Mork bj...@mork.no
+Description:
+ The driver
Bjørn Mork wrote:
Just make doubly sure that you will be ok, for a long time, with using
the ethtool coalescing interface for configuring this because you'll
really be stuck with this forever.
Yes, I am painfull aware of that. So I was hoping someone would jump at
this and say something
Hi Peter,
Peter Chen wrote:
The step at the board:
root@freescale ~$ modprobe libcomposite
I guess this step is unneccessary, and that all neccessary modules
are loaded automatically on demand.
root@freescale ~$ mount none /sys/kernel/config/ -t configfs
root@freescale ~$ mkdir
The USB bus specification says that 255 devices can be connected to the
host, but that doesn't mean the xHCI host controller has all the
internal resources to support that.
To me that sounds like such xHCI HCs can not be considered USB compliant. :\
//Peter
--
To unsubscribe from this
Hola Alejandro,
Alejandro Exojo wrote:
But it seems to be failing quite a lot for me, at least on some kernel
versions. I was expecting that `udevadm info --query=path` or `lsusb
-t` would report exactly the same across reboots if the devices are
the same ones, plugged to the same physical
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
but I did find I had some old IOGEAR USB 1.1 extenders (USB-over-CAT5
cable) and with those, the device does switch into full-speed mode on my
computer:
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
Nope. UHCI was loaded but it didn't recognize any UHCI-compatible
chips so I was left without any USB devices (not even keyboard).
Hmmm. Did you
Alan Stern wrote:
lspci should show the UHCI companion controllers on the PCI bus.
Peter, David's computer doesn't have any UHCI controllers.
Everything is handled by EHCI, through a hub on the motherboard.
This is the standard design for current Intel systems.
Thanks, I understand.
I
David Mosberger wrote:
+++ b/drivers/usb/host/Kconfig
@@ -4,6 +4,16 @@
comment USB Host Controller Drivers
depends on USB
+config USB_MAX3421_HCD
+ tristate MAX3421 HCD (USB-over-SPI) support
+ depends on USB
+ help
+ The Maxim MAX3421E Host Controller
Luke-Jr wrote:
And this is the way that the USB protocol works, a device can not send
data to the host unless it is asked for it. So the host always has to
ask for it.
I'm aware of that - but wouldn't it be possible to just ask less often to
reduce the bandwidth load?
It depends on
Clinton Sprain wrote:
I noticed your examples are both fn combos. I'm seeing something like
this and it seems specifically related to the fn key. Reproducible on a
Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
Press key
Press fn
Release key
Release fn
The key will be 'stuck'
konst...@ngs.ru wrote:
If so, which linux distro is worth being chosen for
building and testing that custom kernel and, especially,
usbip, in particular, and does distro really matter?
It depends on how much value add the distribution has around the
kernel.
The well-known distributions all
Sarah Sharp wrote:
Yes, this is a slight race condition, and we should wait for the
successful event. However, we have not seen any issues with this
race condition.
I'm glad that you say that having the race is wrong (we should) and
I guess that we should wait for the sake of correctness?
Sarah,
Sarah Sharp wrote:
I'm simply trying to see how much of a priority it is to fix this.
I really want to re-architect the code and do this right, and it
will take some time.
Awesome! I think wanting to do it right is very close to
desire for perfection, or at the very least correctness.
Hi Andreas,
Kasberger Andreas wrote:
XHCI Host Controller on Intel Panther Point with CDC/ACM dead after
massive NAK
PCH 82HM76 (PantherPoint) chipset connect with a Renesas RX621
How to reproduce :
No Reader on device /dev/ttyACM0 connected
Writer will send in endless loop always same
Robert Baldyga wrote:
v3:
..
+++ b/tools/usb/aio_multibuff/host_app/Makefile
@@ -0,0 +1,13 @@
+CC = gcc
+LIBUSB_CFLAGS = $(shell pkg-config --cflags libusb-1.0)
+LIBUSB_LIBS = $(shell pkg-config --libs libusb-1.0)
+WARNINGS = -Wall -Wextra
+CFLAGS = $(LIBUSB_CFLAGS) $(WARNINGS)
+LDFLAGS =
David Laight wrote:
Where's the 8k coming from?
My memory, I meant 16k :-(
No problem. But what about that alignment? It seems that userspace
needs to start caring about alignment with xhci, right?
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of
David Mosberger wrote:
The Maxim MAX3421E is the other option, but it has no Linux driver.
You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a
reference that might even work.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
David Mosberger wrote:
David Mosberger wrote:
The Maxim MAX3421E is the other option, but it has no Linux driver.
You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a
reference that might even work.
We are aware of Arduino but the point of our project is to be able to
Nice to have a complete kernel+userspace example. Thanks!
Robert Baldyga wrote:
+++ b/tools/usb/aio_multibuff/host_app/test.c
@@ -0,0 +1,122 @@
+#include libusb-1.0/libusb.h
Please don't do this.
Please always #include libusb.h and call some combination of:
pkg-config --cflags libusb-1.0
Hi all,
I've removed the libusbx-devel list since Pete Batard banned[1] me
after I wrote that I considered the libusbx code to have a bug[2].
Pete Batard wrote:
It is my great pleasure
The hostile fork[3] is a success; you can now call libusbx libusb,
since Nathan Hjelm removed me from the
Soar Hung wrote:
We ported the Linux and related drivers to our embedded
system(a customized board), and using TUSB7340 as our
host controller.
We also write a usb interface driver for the tested device,
the enumeration and bulk in/out transfers work fine.
But we encounter problem
..
Alan Stern wrote:
Should we just drop those warnings?
No opinion.
I think they should stay.
OK, but how about demoting them to debug messages instead of warnings?
If you want to make that change, I don't mind.
I prefer that they stay visible by default, because it
Greg KH wrote:
Ok, given that this is due to really broken hardware, and the use case
is quite rare, and the patch doesn't really solve the problem, I'll
drop it from my queue.
No protest against dropping the patch - but just a note that in the
libusb community we are really big fans of the
Greg KH wrote:
allow both a kernel driver *and* userspace to open a device
at the same time - doing locking when the interfaces is actually
being used by someone.
For USB storage this would mean that unless a filesystem has been
mounted or dd is running on the block device, usbfs
Greg KH wrote:
Ah, ok, that's a bit better, but then we need to figure out some way to
push being used down to a large majority of drivers, which we really
don't have.
And of course not just for storage; allow *all* the classes.
I don't know how much effort it would be for storage - is a
Alan Stern wrote:
I don't know how much effort it would be for storage - is a block
device unaware that it has been mounted?
Those are two separate issues. Firstly, usb-storage is not a block
device drivers; it is a USB driver.
You're of course right, the knowledge needs to travel across
stl wrote:
I am at the moment working on a uClinux 2.6.19.
Don't do that. Work on the absolutely latest source code. If you work
on anything else it is impossible for you to get any help with any
issues, and you will have to spend a lot of extra time to make your
finished work possible to
David Miller wrote:
should all WWAN drivers be moved to only POINTTOPOINT?
I can't answer any of your questions unless you tell me what the
real limitation of these devices is.
It's rather about the network than any given devices, right?
//Peter
--
To unsubscribe from this list: send the
victor wrote:
please remove these sort of footers when you send emails to a public
mailing list ;-)
The footer is auto-inserted by the company email system. I am sorry
about it.
Talk to your company about how it is impossible for you to contribute
to an open source project on a public
Tilman wrote:
I am in the process of writing firmware for an USB device based on
an 8051 core.
What device is that? Is it a Cypress FX2 or an SiLabs C8051?
I am testing it against linux kernel driver.
Depending on the device it may be worth exploring also the libusb
alternative, allowing
Chen Gang wrote:
it is better to let u16 status instead of u16 *status = kmalloc
..
940 int usb_get_status(struct usb_device *dev, int type, int target, void
*data)
941 {
942 int ret;
943 u16 *status = kmalloc(sizeof(*status), GFP_KERNEL);
944
945 if
Linus Walleij wrote:
Windows requests the 0xee string descriptor from *every* device,
unless the same vid and pid has been seen before on the system.
I had no clue about that... have you seen this from USB traces?
I didn't look at traces, but Microsoft documents it, and testing
shows their
Martin Teichmann wrote:
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -192,6 +192,7 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) },
{ USB_DEVICE(FTDI_VID,
Linus Walleij wrote:
If you insert any kind of device into a Windows machine, and Windows
does not find a .inf file for it, it will be probed for the OS
descriptor.
I think it avoids anything with != 3 endpoints of the right type
though.
And basically that is how MTP devices just work on
Rolf Leggewie wrote:
Recently, I was given a usb-to-parallel adapter cable but the
latest mainline kernel does not recognize it. I can't find any
identifying information on the cable itself. Please let me know
what information I can provide to get this supported.
The cable doesn't enumerate
Karl Krach wrote:
Thanks a lot. It seams that the Android [1] has the 'Microsoft OS
Descriptors' implemented while Meego has not. Porting from the Android code
don't seems to be straightforward for me - do you know a better solution?
Reimplement them?
It shouldn't be terribly much work -
Bjørn Mork wrote:
The problem appear when you ask a device which is not MTP
for that descriptor, some of them just die, so I cannot do
that.
Really? You ask for a string descriptor and the device dies? Won't
those devices also die if they are connected to a Windows system?
Yes, but
Linus Walleij wrote:
- some devices bug out on libusb_open()
Please send me a debug log from when this happens. Exact steps are at
http://libusb.org/wiki/debug
I'll see what I can dig up. Mostly this has come from upstream,
Alessio do you have something at hand for these color
Karl Krach wrote:
How to be detected as USB\MS_COMP_MTP?
Microsoft OS Descriptors
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430%28v=vs.85%29.aspx
Hej Linus!
Linus Walleij wrote:
- some devices bug out on libusb_open()
Please send me a debug log from when this happens. Exact steps are at
http://libusb.org/wiki/debug
I have added code like below to libmtp to instead inspect sysfs
*before* starting any libusb-based business.
..
- Is
Miguel Dardenne wrote:
I get a USB disconnect of my external USB HDD about once per day.
Did you already ask PC Engines? They might recognize the problem.
Either 5536 or the driver may still be the problem, but I think it
would be interesting to ping the vendor.
If you'd rather collect more
Avner Flesch wrote:
3.5 is end-of-life, but it should work for your testing for now.
OK - what version do you recommend?
Always use the latest version.
What am I missing?
A host controller driver for your hardware.
//Peter
--
To unsubscribe from this list: send the line unsubscribe
Marek Floriańczyk wrote:
If I say to them log into something like raspberry (without even a
screen) prepare postgresql database dump, load database and so on...
then I'm already lost, no one will do it.
That is the approach of providing no administrative tool at all. I
don't think anyone
1 - 100 of 138 matches
Mail list logo
