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 don't need "new_port" or "re
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 observable we j
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 solution needs re
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 s
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" > new_port
#cat observed_ports
#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
> >>>
> >>>This commit adds a new trigger responsible for t
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 observed_ports
>>> #1-1
>>>
>>>
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 /usr/share
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 i
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 s
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 connected to the specified USB port. This can
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 port. This can can useful for
>> various home rou
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 port. This can can useful for
>> various home rou
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 that have USB port
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 telling user
a device is
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 have it.
>
> There's a lot missing, b
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:
The "inverted" attri
20 matches
Mail list logo
