Thanks for the responses everyone
> IMHO, considering the amount of Android users, we can merge this into
> composite.c itself. Just make the code depend on CONFIG_ANDROID. Or
> something along the lines of
I suspect that once you see what this entails you won't be so willing :)
The code for han
On 06.04.2018 15:03, Felipe Balbi wrote:
[...]
okay, but we don't... Do you wanna send some patches?
another thing to keep in mind is that we're trying to be a USB-compliant
stack. Gadget Framework was never meant to be a testing ground for the
Host Stack. There are VERY flexible tools design
Hi again,
Felipe Balbi writes:
> Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this
mostly
reuses existing functionalities and won't affect users that haven't
enabled
it. Please let me know of any feedbac
Hi,
Krzysztof Opasiak writes:
>>> A few advantages over a couple options I've considered are that this
>>> mostly
>>> reuses existing functionalities and won't affect users that haven't
>>> enabled
>>> it. Please let me know of any feedback on the design or any possible
>>>
On 06.04.2018 14:35, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
On 06.04.2018 12:18, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this mostly
reuses existing functionalities and won't affect users that haven
Hi,
Krzysztof Opasiak writes:
> On 06.04.2018 12:18, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Krzysztof Opasiak writes:
>>
>>
>>
> A few advantages over a couple options I've considered are that this
> mostly
> reuses existing functionalities and won't affect users that haven't
>>
On 06.04.2018 12:18, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this mostly
reuses existing functionalities and won't affect users that haven't enabled
it. Please let me know of any feedback on the design or any possi
Hi,
Krzysztof Opasiak writes:
>>> A few advantages over a couple options I've considered are that this mostly
>>> reuses existing functionalities and won't affect users that haven't enabled
>>> it. Please let me know of any feedback on the design or any possible
>>> implementation issues.
>>
On 06.04.2018 12:12, Felipe Balbi wrote:
Hi Jerry,
Jerry Zhang writes:
Hi all,
I've been looking for a way to handle custom device targeted control
requests from userspace. This would allow us to move away from needing
kernel patches to implement
https://source.android.com/devices/accessor
Hi Jerry,
Jerry Zhang writes:
> Hi all,
>
> I've been looking for a way to handle custom device targeted control
> requests from userspace. This would allow us to move away from needing
> kernel patches to implement
> https://source.android.com/devices/accessories/aoa. It seems like we are
> clo
Hi Jerry,
W dniu 04.04.2018 o 02:04, Jerry Zhang pisze:
Hi all,
I've been looking for a way to handle custom device targeted control
requests from userspace. This would allow us to move away from needing
kernel patches to implement
https://source.android.com/devices/accessories/aoa. It seems l
Hi all,
I've been looking for a way to handle custom device targeted control
requests from userspace. This would allow us to move away from needing
kernel patches to implement
https://source.android.com/devices/accessories/aoa. It seems like we are
close to being able to do this. With the flag FUN
12 matches
Mail list logo
