On 29 August 2016 at 10:41, Pavel Machek wrote:
> On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
>> On 29 August 2016 at 10:05, Pavel Machek wrote:
>> >> >2) Having "ports" subdir with RW files, one per each existing physical
>> >> >port
>> >> >In this situation we
On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
> On 29 August 2016 at 10:05, Pavel Machek wrote:
> >> >2) Having "ports" subdir with RW files, one per each existing physical
> >> >port
> >> >In this situation we don't need "new_port" or "remove_port". If we
> >> >want port to be
On 08/26/2016 09:50 PM, Pavel Machek wrote:
On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote:
On 08/25/2016 04:30 PM, Alan Stern wrote:
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
I'd see it as follows:
#cat available_ports
#1-1 1-2 2-1
#echo "1-1" > new_port
#cat observed_ports
#1-1
On 29 August 2016 at 10:05, Pavel Machek wrote:
>> >2) Having "ports" subdir with RW files, one per each existing physical port
>> >In this situation we don't need "new_port" or "remove_port". If we
>> >want port to be observable we just do:
>> >echo 1 > 1-1
>> >Implementing this
Hi!
> >2) Having "ports" subdir with RW files, one per each existing physical port
> >In this situation we don't need "new_port" or "remove_port". If we
> >want port to be observable we just do:
> >echo 1 > 1-1
> >Implementing this solution needs reading more details from USB subsystem.
>
> The
On 08/26/2016 05:58 PM, Rafał Miłecki wrote:
On 25 August 2016 at 20:48, Jacek Anaszewski wrote:
On 08/25/2016 04:30 PM, Alan Stern wrote:
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
I'd see it as follows:
#cat available_ports
#1-1 1-2 2-1
#echo "1-1" >
On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote:
> On 08/25/2016 04:30 PM, Alan Stern wrote:
> >On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
> >
> >>I'd see it as follows:
> >>
> >>#cat available_ports
> >>#1-1 1-2 2-1
> >>
> >>#echo "1-1" > new_port
> >>
> >>#cat observed_ports
> >>#1-1
> >>
>
On Thu 2016-08-25 11:04:38, Jacek Anaszewski wrote:
> On 08/25/2016 10:29 AM, Rafał Miłecki wrote:
> >On 25 August 2016 at 10:03, Jacek Anaszewski
> >wrote:
> >>On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
> >>>
> >>>From: Rafał Miłecki
> >>>
>
On 25 August 2016 at 20:48, Jacek Anaszewski wrote:
> On 08/25/2016 04:30 PM, Alan Stern wrote:
>>
>> On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
>>
>>> I'd see it as follows:
>>>
>>> #cat available_ports
>>> #1-1 1-2 2-1
>>>
>>> #echo "1-1" > new_port
>>>
>>> #cat
On Thu, 25 Aug 2016, Alan Stern wrote:
> > Does the lsusb command do the mapping in the user space or maybe
> > it takes the names from kernel?
>
> lsusb does the mapping in userspace, based on an ID database. On my
> system (Fedora), the database is /etc/udev/hwdb.bin.
There's also
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
> >>> What kind of description do you mean? Where should it be used / where
> >>> should it appear?
> >>>
> >>
> >> Product name/symbol. Actually it should be USB subsystem responsibility
> >> to provide the means for querying the product name by port
On 08/25/2016 04:30 PM, Alan Stern wrote:
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
I'd see it as follows:
#cat available_ports
#1-1 1-2 2-1
#echo "1-1" > new_port
#cat observed_ports
#1-1
#echo "2-1" > new_port
#cat observed_ports
#1-1 2-1
We've already had few discussions about the
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
> I'd see it as follows:
>
> #cat available_ports
> #1-1 1-2 2-1
>
> #echo "1-1" > new_port
>
> #cat observed_ports
> #1-1
>
> #echo "2-1" > new_port
>
> #cat observed_ports
> #1-1 2-1
>
> We've already had few discussions about the sysfs designs
On 08/25/2016 10:29 AM, Rafał Miłecki wrote:
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB
device gets
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
> On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
>>
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
> On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
>>
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB
On 25/08/16 10:03, Jacek Anaszewski wrote:
zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers
zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED
On 24 August 2016 at 20:48, Bjørn Mork wrote:
> Rafał Miłecki writes:
>
>> The last big missing thing is Documentation update (this is why I'm
>> sending RFC). Greg pointed out we should have some entries in
>> Documentation/ABI, but it seems none of triggers
Rafał Miłecki writes:
> The last big missing thing is Documentation update (this is why I'm
> sending RFC). Greg pointed out we should have some entries in
> Documentation/ABI, but it seems none of triggers have it.
There's a lot missing, but there is at least one exception:
From: Rafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.
The trigger gets
21 matches
Mail list logo