[systemd-devel] systemd-user and xdg-user-dir

[Jakob Schürz]

Hi there!

I can not find anything valuable for my problem. So i come here...

in ~/.config/user-dirs.dirs are xdg-specific directories for desktop,
downloads and so on. You know this.

I rewrote a fuse-Filesystem for cups and want wo provide it with a
systemd-unit.

There should be a Directory on the desktop called "Printer". In english.
But my Desktop is called "Schreibtisch", because i'm from Austria... And
printers are called "Drucker" here.

if i create a new xdg-user-dir with

$ xdg-user-dirs-update --set PRINTERS $(xdg-user-dir DESKTOP)/Drucker

I get back:

$ xdg-user-dir PRINTERS
/home/jakob/Schreibtisch/Drucker

As expected and wanted.

Now i want to use this XDG_PRINTERS_DIR-Variable in systemd.mount and
systemd.path... in a systemd-user-session.

I made a separate unit to set the environment:

[Unit]
Description=Set environment

[Service]
Type=simple
ExecStart=/bin/sh -c '/bin/systemctl --user set-environment
XDG_PRINTERS_DIR=$(xdg-user-dir PRINTERS)'


But i want to activate this fuse-filesystem only if the directory
$XDG_PRINTERS_DIR exist. But systemd.path accepts no Variable for
"PathExists=..."

How can I manage this path-Unit?

Regards

Jakob
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  wrote:

> On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> > On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > >
> > >
> > > On Jan 10, 2017 18:19, "Greg KH"  wrote:
> > >
> > > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > > I figured that made most sense :)
> > > >
> > > > Still, it would be good if we could have a rule to not grab
> > > the CDC
> > > interface
> > > > part if the device includes WebUSB functionality.
> > >
> > > What exactly do you mean by "grab"?
> > >
> > > MM probing :)
> >
> > Probe should be fine, right?  Are you really thinking that MM needs
> > to
> > go "oh look, a cdc device, let's go look at all of the raw interfaces
> > to
> > ensure it really isn't a webusb device as well before I touch it!"
> >
> > That way lies madness...
> >
> > What's wrong with touching it?  The kernel already did, why would
> > userspace care?
>
> And we're quite happy to keep blacklisting specific VID/PID combos we
> know are not modems. Another possible solution is to greylist devices
> that happen to have webusb descriptors, such that they won't get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd rather that
> happen via udev rules than MM trying to walk USB device attributes and
> parsing webusb descriptors.
>

Actually, that sounds like a very good compromise.  I remember my own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the probing) all
while the system thought it could already start speaking with the device
over e.g. chrome.serial.  Eventually you (modemmanager) were kind enough to
get our VID/PID listed and ChromeOS was quick to pick it up (~5-6 months to
get in stable) and ubuntu so kind to upgrade to the version of modemmanager
including our blacklisting approx 2.5 years later (sigh) ;)

If greylisting prevents auto-probing, I think it would be very valuable for
devices with a WebUSB header because those will in most cases (as I see
them used) be industrial things (like my current medical company employer)
or IoT devices.  And waiting ~16 seconds for a fallback to USB Serial where
WebUSB is not available (or for other reasons not chosen), can be a real
pain.

I agree that a solid udev rule would be a good way forward (I'll look into
greylisting and see if I can come up with something that covers) and maybe
this could also be the place to do the user space access (or not - I'll try
to come back with something.

thanks for all the input.  Maybe Kenneth, Reilly or some working on USB
related things in Intel have something to add?


>
> Dan
>
> > > > The likelihood of a modem+WebUSB combo is so small that it
> > > must fall
> > > > in the category where potential rare exotic devices combining
> > > it must
> > > > be whitelisted and the rest be left alone.
> > >
> > > I think you misunderstand just how crazy firmware authors can
> > > be.  I'm
> > > sure we will see those types of devices in the wild.
> > >
> > > ...But realistically how many? Bothering 99.9% to support the
> > > special case
> > > seems less logical than just finding the 0.1% and whitelisting it
> > > (if needed)
> >
> > That's the joy of writing an operating system for all devices on the
> > planet, those 0.1% can be a lot of devices :)
> >
> > Anyway, I don't think there's much to do here just yet, let's wait
> > and
> > see just how bad these webusb devices end up looking like...
> >
> > thanks,
> >
> > greg k-h
> > ___
> > ModemManager-devel mailing list
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > 
> > 
> > On Jan 10, 2017 18:19, "Greg KH"  wrote:
> > 
> > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > I figured that made most sense :)
> > >
> > > Still, it would be good if we could have a rule to not grab
> > the CDC
> > interface
> > > part if the device includes WebUSB functionality.
> > 
> > What exactly do you mean by "grab"?
> > 
> > MM probing :)
> 
> Probe should be fine, right?  Are you really thinking that MM needs
> to
> go "oh look, a cdc device, let's go look at all of the raw interfaces
> to
> ensure it really isn't a webusb device as well before I touch it!"
> 
> That way lies madness...
> 
> What's wrong with touching it?  The kernel already did, why would
> userspace care?

And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus.  But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.

Dan

> > > The likelihood of a modem+WebUSB combo is so small that it
> > must fall
> > > in the category where potential rare exotic devices combining
> > it must
> > > be whitelisted and the rest be left alone.
> > 
> > I think you misunderstand just how crazy firmware authors can
> > be.  I'm
> > sure we will see those types of devices in the wild.
> > 
> > ...But realistically how many? Bothering 99.9% to support the
> > special case
> > seems less logical than just finding the 0.1% and whitelisting it
> > (if needed)
> 
> That's the joy of writing an operating system for all devices on the
> planet, those 0.1% can be a lot of devices :)
> 
> Anyway, I don't think there's much to do here just yet, let's wait
> and
> see just how bad these webusb devices end up looking like...
> 
> thanks,
> 
> greg k-h
> ___
> ModemManager-devel mailing list
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 18:19, "Greg KH"  wrote:

On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> I figured that made most sense :)
>
> Still, it would be good if we could have a rule to not grab the CDC
interface
> part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?

MM probing :)


> The likelihood of a modem+WebUSB combo is so small that it must fall
> in the category where potential rare exotic devices combining it must
> be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be.  I'm
sure we will see those types of devices in the wild.

...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if
needed)


> Also (probably more a generic udev/systemd patch) always give user (or at
least
> browser - if that differentiation is possible) access to WebUSB devices.

That's a bit harder as it requires userspace to parse the headers and
"know" to allow access to the device.  I suggest a udev helper program
for it.

good luck,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 18:19, "Greg KH"  wrote:
> 
> On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > I figured that made most sense :)
> >
> > Still, it would be good if we could have a rule to not grab the CDC
> interface
> > part if the device includes WebUSB functionality.
> 
> What exactly do you mean by "grab"?
> 
> MM probing :)

Probe should be fine, right?  Are you really thinking that MM needs to
go "oh look, a cdc device, let's go look at all of the raw interfaces to
ensure it really isn't a webusb device as well before I touch it!"

That way lies madness...

What's wrong with touching it?  The kernel already did, why would
userspace care?

> > The likelihood of a modem+WebUSB combo is so small that it must fall
> > in the category where potential rare exotic devices combining it must
> > be whitelisted and the rest be left alone.
> 
> I think you misunderstand just how crazy firmware authors can be.  I'm
> sure we will see those types of devices in the wild.
> 
> ...But realistically how many? Bothering 99.9% to support the special case
> seems less logical than just finding the 0.1% and whitelisting it (if needed)

That's the joy of writing an operating system for all devices on the
planet, those 0.1% can be a lot of devices :)

Anyway, I don't think there's much to do here just yet, let's wait and
see just how bad these webusb devices end up looking like...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I figured that made most sense :)

Still, it would be good if we could have a rule to not grab the CDC
interface part if the device includes WebUSB functionality. The likelihood
of a modem+WebUSB combo is so small that it must fall in the category where
potential rare exotic devices combining it must be whitelisted and the rest
be left alone.

Also (probably more a generic udev/systemd patch) always give user (or at
least browser - if that differentiation is possible) access to WebUSB
devices.

Btw: Afaik, Chromebooks are still using modemmanager, where not even
experts have easy access to creating udev rules

Br
Lars

Br
Lars

On Jan 10, 2017 17:34, "Dan Williams"  wrote:

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen 
> wrote:
>
> > A small update:  When the modemmanager finishes probing (~16 secs
> > after
> > connection) data seems to stop flowing in from the WebUSB bulk
> > endpoint
> > also.  It is, however, possible to reconnect and get data again -
> > so I need
> > to see if there should be anything in the mbed firmware causing
> > that
> > behavior or there is some sort of silent reset of
> > interfaces/endpoints
> > happening on the linux side when probing is done.
> >
>
> Had to separate the CDC and WebUSB serial control signals completely
> in the
> firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently.  Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

> >
> > On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen 
> > wrote:
> >
> > > I finally managed to make a configuration that *seems* to work
> > > and I
> > > realize that I may have had something else blocking the WebUSB
> > > interface
> > > (2) while modemmanager was communicating with the CDC_ACM
> > > interface (1).
> > >
> > > I made a clean arbitrary VID/PID and get what seems to be a
> > > functioning
> > > WebUSB (now) while modemmanager sends "AT...AT..." to the CDC
> > > interface -
> > > so while I thought the modemmanager grabbed my WebUSB interface
> > > part, it
> > > must have been because of a faulty combination on my side - my
> > > apologies.
> > > WebUSB actually *does* seem to give immediate "bulk" access to a
> > > device
> > > otherwise claimed by modemmanager - a very nice option to have
> > > and sorry
> > > for the confusion I had that modemmanager grabbed more interfaces
> > > than it
> > > should have.
> > >
> > > Still, the original request still stands and please tell me if
> > > it's a
> > > viable path:
> > >
> > > 1.  If a device has a WebUSB descriptor, it's most probably *not*
> > > a modem
> > > - and should in stead be considered a device that in this rare
> > > case needs
> > > to be whitelisted (as modem), while defaulting to not being
> > > it.  This is to
> > > ease the usage from non-browsers to the same hardware, which can
> > > then
> > > happen immediately and not be required to fail and wait over the
> > > modemmanager probing period (30 sec?) - related to modemmanager
> > > 2. If a device has a WebUSB descriptor, at least the interface
> > > linked to
> > > WebUSB should be made accessible in user land by default so no
> > > average user
> > > has to figure out how to do udev rules - related to udev/systemd
> > >
> > > my headers that seem to work now for the case above:
> > >
> > > Bus 002 Device 089: ID 1209:d010 InterBiometrics
> > > Device Descriptor:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 empriKit|MOTION
> > >   iSerial 3 00.01
> > >   bNumConfigurations  1
> > >   Configuration Descriptor:
> > > bLength 9
> > > bDescriptorType 2
> > > wTotalLength   90
> > > bNumInterfaces  3
> > > bConfigurationValue 1
> > > iConfiguration  0
> > > bmAttributes 0xc0
> > >   Self Powered
> > > MaxPower  100mA
> > > Interface Descriptor:
> > >   bLength 9
> > >   bDescriptorType 4
> > >   bInterfaceNumber0
> > >   bAlternateSetting   0
> > >   bNumEndpoints   1
> > >   bInterfaceClass 2 Communications
> > >   bInterfaceSubClass  2 Abstract (modem)
> > >   

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen 
> wrote:
> 
> > A small update:  When the modemmanager finishes probing (~16 secs
> > after
> > connection) data seems to stop flowing in from the WebUSB bulk
> > endpoint
> > also.  It is, however, possible to reconnect and get data again -
> > so I need
> > to see if there should be anything in the mbed firmware causing
> > that
> > behavior or there is some sort of silent reset of
> > interfaces/endpoints
> > happening on the linux side when probing is done.
> > 
> 
> Had to separate the CDC and WebUSB serial control signals completely
> in the
> firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently.  Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

> > 
> > On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen 
> > wrote:
> > 
> > > I finally managed to make a configuration that *seems* to work
> > > and I
> > > realize that I may have had something else blocking the WebUSB
> > > interface
> > > (2) while modemmanager was communicating with the CDC_ACM
> > > interface (1).
> > > 
> > > I made a clean arbitrary VID/PID and get what seems to be a
> > > functioning
> > > WebUSB (now) while modemmanager sends "AT...AT..." to the CDC
> > > interface -
> > > so while I thought the modemmanager grabbed my WebUSB interface
> > > part, it
> > > must have been because of a faulty combination on my side - my
> > > apologies.
> > > WebUSB actually *does* seem to give immediate "bulk" access to a
> > > device
> > > otherwise claimed by modemmanager - a very nice option to have
> > > and sorry
> > > for the confusion I had that modemmanager grabbed more interfaces
> > > than it
> > > should have.
> > > 
> > > Still, the original request still stands and please tell me if
> > > it's a
> > > viable path:
> > > 
> > > 1.  If a device has a WebUSB descriptor, it's most probably *not*
> > > a modem
> > > - and should in stead be considered a device that in this rare
> > > case needs
> > > to be whitelisted (as modem), while defaulting to not being
> > > it.  This is to
> > > ease the usage from non-browsers to the same hardware, which can
> > > then
> > > happen immediately and not be required to fail and wait over the
> > > modemmanager probing period (30 sec?) - related to modemmanager
> > > 2. If a device has a WebUSB descriptor, at least the interface
> > > linked to
> > > WebUSB should be made accessible in user land by default so no
> > > average user
> > > has to figure out how to do udev rules - related to udev/systemd
> > > 
> > > my headers that seem to work now for the case above:
> > > 
> > > Bus 002 Device 089: ID 1209:d010 InterBiometrics
> > > Device Descriptor:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 empriKit|MOTION
> > >   iSerial 3 00.01
> > >   bNumConfigurations  1
> > >   Configuration Descriptor:
> > > bLength 9
> > > bDescriptorType 2
> > > wTotalLength   90
> > > bNumInterfaces  3
> > > bConfigurationValue 1
> > > iConfiguration  0
> > > bmAttributes 0xc0
> > >   Self Powered
> > > MaxPower  100mA
> > > Interface Descriptor:
> > >   bLength 9
> > >   bDescriptorType 4
> > >   bInterfaceNumber0
> > >   bAlternateSetting   0
> > >   bNumEndpoints   1
> > >   bInterfaceClass 2 Communications
> > >   bInterfaceSubClass  2 Abstract (modem)
> > >   bInterfaceProtocol  1 AT-commands (v.25ter)
> > >   iInterface  0
> > >   CDC Header:
> > > bcdCDC   1.10
> > >   CDC Call Management:
> > > bmCapabilities   0x03
> > >   call management
> > >   use DataInterface
> > > bDataInterface  1
> > >   CDC ACM:
> > > bmCapabilities   0x02
> > >   line coding and serial state
> > >   CDC Union:
> > > bMasterInterface0
> > > bSlaveInterface 1
> > >   Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 08:39:28AM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 07:51, "Greg KH"  wrote:
> 
> On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
> > On 2017-01-09 9:55 am, Greg KH wrote:
> > > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > > Greg KH  writes:
> > > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde
> Christiansen wrote:
> > > > >> Web USB can only grab devices which has special Web USB headers.
> It can not
> > > > >> grab any USB device.
> > > > >>
> > > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > > >
> > > > > Ah, fun :(
> > > > >
> > > > > So, we can add a quirk into the kernel cdc-acm driver to never 
> bind
> to a
> > > > > device that has the wusb platform capability descriptor,
> > > >
> > > > I fail to see why a quirk should be necessary. New device classes 
> are
> > > > expected to use new class/subclass codes distintly different from
> > > > anything handled by existing class drivers.
> > >
> > > One would hope, but it seems like they want to piggy-back on the
> cdc-acm
> > > spec.  But I could be totally wrong here, does anyone have the actual
> > > descriptor dump of a device anywhere?
> >
> > We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> > always have its interfaces marked vendor-specific. Below is an example 
> of
> a
> > device which implements both a CDC-ACM interface and a WebUSB interface.
> 
> Ick, why would you want both interfaces on a device?  Are you going to
> allow firmware to talk to both endpoints at the same time?  Why?
> 
> Why not just make it a "one interface" type of device?
> 
> I work for a medical company, where we are using long lived software and
> hardware. Having the option of supporting both WebUSB and USB serial will 
> allow
> us to move to pure web and still support legacy platforms.
> 
> If we - in stead - were to only have WebUSB or standard CDC, we would force an
> impossible break.

Ok, yes, different interfaces will work, and as long as the kernel isn't
going to bind to the interface, you should be fine.  Hopefully your
firmware can handle userspace talking to both interfaces at the same
time :)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel