Should wsl-boot-program create XDG_RUNTIME_DIR?

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

[-- Attachment #1.1.1: Type: text/plain, Size: 1414 bytes --]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:

1. when logged in, there is a warning says:
  > warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'

The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].

This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.

2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).

I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?

[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87
[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

-- 
dan

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 8669 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

[-- Attachment #1.1.1: Type: text/plain, Size: 1414 bytes --]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:

1. when logged in, there is a warning says:
  > warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'

The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].

This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.

2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).

I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?

[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87
[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

-- 
dan

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 8669 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

[-- Attachment #1.1.1: Type: text/plain, Size: 1413 bytes --]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:

1. when logged in, there is a warning says:
 > warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'

The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].

This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.

2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).

I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?

[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87
[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

-- 
dan

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 8669 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

[Maxim Cournoyer]

Hi Dan,

dan <i@dan.games> writes:

> Hello guix,
>
> Even since the WSL image was pushed to master branch, I've been
> spending time experimenting with it.  It almost runs smoothly, unless
> two points:
>
> 1. when logged in, there is a warning says:
>> warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't
>   execute anything.  You can check if xdg runtime directory exists,
>   XDG_RUNTIME_DIR variable is set to appropriate value and manually
>   execute the script by running '$HOME/.guix-home/on-first-login'
>
> The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user
> directory is empty.  I believe the /run directory is created on WSL's
> side, and there is a step remounting it[1].
>
> This also makes home shepherd services unusable.  Although I could
> manually create the directory, perhaps it's better if we could just do
> the work within `wsl-boot-program', a wrapper for the login shell to
> work properly on WSL.

If it breaks a valid use case as it seems to be, it should be handled by
Guix.  A similar problem was fixed for the etc/guix-install.sh installer
script; it now defines a default value for XDG_RUNTIME_DIR and others in
its sys_create_init_profile function.

> 2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12
> gallium driver[2]. So when opening up a GUI software in guix on WSL,
> in renders through llvmpipe (using CPU not GPU).
>
> I'm not sure if building mesa with d3d12 driver enabled by default is
> a good idea, or maybe we could create a new package?

A variant package would mean rebuilding many things, so if we want to
support this use case it seems we'd have to enable d3d12 in our main
mesa package and see what are the costs of doing so (increased disk
space?  new dependencies?).

-- 
Thanks,
Maxim

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

[John Kehayias]

Hi Maxim and Dan,

On Tue, Nov 15, 2022 at 04:13 PM, Maxim Cournoyer wrote:

> Hi Dan,
>
> dan <i@dan.games> writes:
>
>> 2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12
>> gallium driver[2]. So when opening up a GUI software in guix on WSL,
>> in renders through llvmpipe (using CPU not GPU).
>>
>> I'm not sure if building mesa with d3d12 driver enabled by default is
>> a good idea, or maybe we could create a new package?
>
> A variant package would mean rebuilding many things, so if we want to
> support this use case it seems we'd have to enable d3d12 in our main
> mesa package and see what are the costs of doing so (increased disk
> space?  new dependencies?).

At the very least Mesa will need the DirectX headers. That may be it?

There are several Mesa updates over on core-updates, so if anyone wanted to try out adding that option, you should use the core-updates version. I think you'll only need the newer libdrm and wayland-protocols from there and should otherwise build fine on master.

John

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

Hi John,

On 11/16/2022 11:00 AM, John Kehayias wrote:
> At the very least Mesa will need the DirectX headers. That may be it?

According to the document of mesa[1], I believe it's doing more than 
just including headers:
> The D3D12 driver is a Gallium driver that emits API calls for Microsoft’s D3D12 API instead of targeting a specific GPU architecture.
Anyway, I could take the effort into investigating if it's gonna work on 
WSL if we add d3d12 support to the gallium3d driver, but I'm afraid I 
don't have the ability to test if it breaks anything on other platform / 
for other use cases.

[1]: https://docs.mesa3d.org/drivers/d3d12.html
-- 
dan

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

[John Kehayias]

Hi Dan,

On Wed, Nov 16, 2022 at 11:45 AM, dan wrote:

> Hi John,
>
> On 11/16/2022 11:00 AM, John Kehayias wrote:
>> At the very least Mesa will need the DirectX headers. That may be it?
>
> According to the document of mesa[1], I believe it's doing more than
> just including headers:
>> The D3D12 driver is a Gallium driver that emits API calls for Microsoft’s D3D12 API
>> instead of targeting a specific GPU architecture.

Right, but that might just need the headers to know the API calls to make. My quick look at the build option discussions only referenced needing the headers. I would start there and see how far it gets :)

> Anyway, I could take the effort into investigating if it's gonna work on
> WSL if we add d3d12 support to the gallium3d driver, but I'm afraid I
> don't have the ability to test if it breaks anything on other platform /
> for other use cases.
>

Well Mesa updates go on core-updates anyway, so there is time (to test). I saw that Arch, for instance, enables this option in their regular Mesa build, for what that's worth.

Good luck!

> [1]: <https://docs.mesa3d.org/drivers/d3d12.html>