2012/7/3 Tobias Powalowski :
> Hi guys,
> got that bugreport:
> https://bugs.archlinux.org/task/30467
>
> any idea how to solve it?
Why is the lib called libusb.a and not libusb-1.0.a?
My hypothesis is that libusb.a comes from libusb-compat and is not
(statically) linked with libusb (or libusbx).
Hi guys,
got that bugreport:
https://bugs.archlinux.org/task/30467
any idea how to solve it?
thanks
greetings
tpowa
--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org
signature.asc
Description: OpenPGP digital signature
As per the roadmap. This is something I realized right after 1.0.12, as
LOG_LEVEL_XYZ is lilely to be generic enoug to conflict with other apps
and headers that may define those as well.
This is also in part the source of Trac #31, which is an issue with
libusb-compat, as libusb-compat's core.
On 2012.07.02 18:46, Chuck Cook wrote:
> At the very bottom of Makefile.am :
>
> dist-up: dist
> rm -rf $(reldir)
> mkdir -p $(reldir)
> cp $(distdir).tar.bz2 $(reldir)
> rsync -rv $(reldir)
> frs.sourceforge.net:/home/frs/project/l/li/libusb/libusb-1.0/
> rm -rf $(rel
Kevyn-Alexandre Paré wrote:
>
>>
>> If timerfd is available on your system, to manage timer expirations
>> through a file descriptor, that's added to the POLLIN list.
> thx, The linux kernel that I'm using have timerfd enable!
>
> One question remains, how to distinguish the files descriptor from e
On Tue, Jun 26, 2012 at 01:16:46PM +0400, Igor Kuzmin wrote:
> OK, so, with for-usb-linus kernel current results with different
> controllers are:
> NEC - works
> Fresco Logic - fails with "ERROR Transfer event TRB DMA ptr not part of
> current TD"
Doesn't surprise me. Fresco Logic host controlle
At the very bottom of Makefile.am :
dist-up: dist
rm -rf $(reldir)
mkdir -p $(reldir)
cp $(distdir).tar.bz2 $(reldir)
rsync -rv $(reldir)
frs.sourceforge.net:/home/frs/project/l/li/libusb/libusb-1.0/
rm -rf $(reldir)
The rsync command appears to point to a libusb relate
On 2012.06.30 11:33, Xiaofan Chen wrote:
> https://libusb.org/ticket/136
>
> Not so sure if this is a real bug or not.
I'm hoping it won't be too difficult to confirm with a modified
xusb/plain sample that uses the OP's code, but only loops for 100 or
1000 iterations instead of indefinitely, and
On 2012.06.30 11:15, Xiaofan Chen wrote:
> The patch reduced some warnings but there are still 3 warnings
> remained. Actually the three warnings are basically the same though.
> ../../libusbx/libusb/sync.c:84:28: warning: Result of 'malloc' is
> converted to a pointer of type 'unsigned char', whi