On 2013.08.04 15:33, Alan Stern wrote:
>> So, provided this is all we'd need to do to avoid pollution on Windows,
>> your preference would be for libusb to cancel its established contract
>> (I think it's explicitly documented) to cache the config descriptors on
>> all platforms?
>
> Not at all. A
On 2013.08.04 07:46, Hans de Goede wrote:
>> So I may be misremembering things, as the data we seem to derive from
>> the first IOCTL isn't used for the topology, but to cache the actual
>> config descriptor (which libusb mandates us to cache) and it looks like
>> it's really a matter of caching ou
On 2013.08.04 07:41, Hans de Goede wrote:
> I believe the discussion between you and Alan has hopefully made it
> clear why this is a bad idea.
Not in the slightest.
It's not because something is difficult to accomplish (i.e. may require
_workarounds_ for flaky devices) that it's a bad idea.
Cac
Hi,
wanted to point out that checking if SOCK_CLOEXEC is defined as done in
https://github.com/libusbx/libusbx/commit/242d49c636b390d64740b79953c68c2b28cae8ff
is not enough. SOCK_CLOEXEC might be defined in one of the libc-headers (libc
= glibc, uClibc, etc.) but actually not supported by the k
On Sun, 4 Aug 2013, Pete Batard wrote:
> > This is where I (and probably Hans) disagree. The central server
> > should cache whatever it needs and -- on demand -- whatever clients ask
> > for. Nothing more, unless the server's back end can get the data
> > directly from the OS without any USB tr
Hi,
On 08/03/2013 07:42 PM, Pete Batard wrote:
> On 2013.08.03 16:41, Hans de Goede wrote:
>> Really doing any IO at all on enumeration is a big no no.
>
> The proposal is simply about duplicating the IO we expect the OS to
> perform naturally,
I believe the discussion between you and Alan has
Hi,
On 08/04/2013 03:08 AM, Pete Batard wrote:
> On 2013.08.04 00:51, Alan Stern wrote:
>> Out of curiosity, what data do you need to request from the parent hub?
>
> Now that I've looked a bit through old e-mails, it seems that these are
> config descriptors, coming from a Windows
> IOCTL_USB_GET
