wpilib.firstdriverstation: init at 2027.0.0-alpha-2

[nullcubee]

Closes #70

Opening as draft because I'd like some testing to take place as well as fixing the couple bugs I have found so far.

Otherwise, the app seems to work great, joysticks show up, all the buttons seem to work, the log viewer works too. But of course I don't have a Systemcore to actually test it with.

Issues:

Trying to set the dashboard to "Elastic" fails with the following line in the terminal:

xdg-open: file '/home/nullcube/wpilib/2027_alpha4\elastic\elastic_dashboard' does not exist

I think this will have to be fixed upstream, the main solutions I can think of are either add a fallback to PATH for our special sauce case where we add elastic_dashboard to PATH, or adding a feature to allow people to define a custom path in the app.

Any thoughts?

---

"Renew DHCP Lease" button fails with the following error:

dhclient failed, falling back to dhcpcd: An error occurred trying to start process 'dhclient' with working directory '/home/nullcube/git/frc-nix'. No such file or directory
read_config: /etc/dhcpcd.conf: No such file or directory
main: mkdir: /var/lib/dhcpcd: Permission denied
main: mkdir: /var/run/dhcpcd: Permission denied
main: pidfile_lock: /var/run/dhcpcd/pid: No such file or directory
Process 'dhcpcd -n' exited with code 1

This is a similar error to the one I get from just running dhcpcd -n as a normal user.

This is related to wpilibsuite/FirstDriverStation-Public#3, except with dhcpcd instead.

Additionally, dhclient is deprecated and has been removed from nixpkgs and other distros:
https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/5/diffs
https://www.isc.org/blogs/dhcp-client-relay-eom/

---

autoPatchelfHook wants the libraries "libGLES_CM.so.1" and "libsteam_api.so" for the program, however I don't believe either of these are included in nixpkgs, and the program seems to work fine without them, so I've added them to the ignored list.

---

The driver station is coded such that it pulls libHarfBuzzSharp.so and libSkiaSharp.so in the local directory relative to the binary, and not from the conventional LD_LIBRARY_PATH as one would expect for .so files. I'm not sure if this is an actual issue or not, and if so it should be reported upstream.

As such I have had to place the binary in $out/lib and used makeWrapper, which isn't that big of a deal, but again, might be something that needs to be reported upstream.

Neither of these libs appear to be included in nixpkgs, except for in the outputs of other programs, such as git-credential-manager. I suspect this has something to do with the framework of the app, (it appears to be dotnet related) but I don't think I know enough to be sure.

Things to test:

• Does it work with Systemcore
• Input group shenanigans
• udev rules
• E-Stop (related to input group and udev)
• Ensure all the functions work as intended

Finally, as suggested, a module should probably be made for this for at least the udev rules if not also say network configuration stuff. The program does require avahi libs so I suspect that will need to be enabled for full functionality.

Please let me know any and all feedback, comments, and questions!

[nullcubee]

Ah, that CI issue will need to get fixed also.

[taciturnaxolotl]

thank you! might it be possible to maybe make it add elastic to path only if it was already been added to the system? we could maybe do some sort of dummy app otherwise that alerts that its not installed so it doesn't just crash

[blaze-developer]

I am in possession of a Systemcore unit, I can get to testing this if you would like. Have any specific things I should test? Ill start checking the list you have, anything specifically just lmk.

[taciturnaxolotl]

arg; I forgot that requires commits to be resigned.

[blaze-developer]

this is all i get. Also, are you planning on adding a desktop entry? I am on a laptop, so id assume the keyboard exists haha.

[blaze-developer]

I added my user to the input group, not sure if there was anything that frc-nix could have done about that.

[taciturnaxolotl]

not sure if this is the best way to structure the module but it should expose it to programs.firstdriverstation.enable

[blaze-developer]

What udev rules necessitate a security wrapper?

[taciturnaxolotl]

isn't it needed for the setguid bit on the binary?

[blaze-developer]

I don't know what that is ;-;. What doesn't work without the wrapper? It seems to load just fine, is there something specifically that requires it? Excuse my maybe stupid question :)

[blaze-developer]

Fyi your wrapper looks for "pkgs.firstdriverstation" but its in "pkgs.wpilib.firstdriverstation"

[taciturnaxolotl]

i knew i did something wrong 🤦 not having my linux box has been really annoying

[blaze-developer]

I think you need to specify an owner of the wrapper:

error: The option `security.wrappers.FirstDriverStation.owner' was accessed but has no value defined. Try setting the option.

Im still unsure why this is neccessary, let me know what I'm missing.

[taciturnaxolotl]

hmm; can you try deleting the wrapper section and seeing if it still works?

[blaze-developer]

config = lib.mkIf cfg.enable {
  environment.systemPackages = with pkgs; [
    pathplanner
    choreo
    wpilib.roborioteamnumbersetter
    wpilib.sysid
    wpilib.wpical
    wpilib.firstdriverstation
    direnv

    advantagescope
    elastic-dashboard
  ] ++ (with stable; [
    emscripten
  ]) ++ lib.optionals cfg.systemcore [
    advantagescope-2027
    elastic-2027
  ];

  # AdvantageScope XR
  networking.firewall.allowedTCPPorts = [ 56328 5810 1735 6767 ];
};

This is my robotics module, I just add the package, and it runs just fine. Is there something specific in the app that wont work without a security wrapper? (I also added my user to the input group)

[taciturnaxolotl]

very interesting; it is mentioned as needing the setguid bit in their readme but perhaps that's wrong

[taciturnaxolotl]

ill remove the module then and add a note to the readme to add the package to the udev groups

[blaze-developer]

The readme says that it needs "hidraw" for proper controller access. Ill plug a controller in when I get home and take a look.

[blaze-developer]

It also says you have to "add the app to the input group" but I just put my user in the input group and it opened. Im not sure how much testing they have done on Linux.

(snippet start)

Additionally, the app needs to be a part of the input group in order to have input access. That can be done with the following commands.

sudo chgrp input FirstDriverStation
sudo chmod g+s FirstDriverStation

Finally, for proper controller access, the current user needs access to hidraw. To do that, create a /etc/udev/rules.d/72-hidraw.rules containing

# Grant access to all hidraw devices for the active user
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0660", TAG+="uaccess"

Then reload udev rules. sudo udevadm control --reload-rules && sudo udevadm trigger

(snippet end)

[blaze-developer]

Oh, one more thing, maybe add a note under the driverstation section on the README that states there will be no support from FIRST or WPILib using frc-nix's distribution of the FIRST Driver Station, and that it is not competition legal. Just to make sure we are making that clear. I think that would align with what WPILib would want.

[blaze-developer]

Gamepads work with the configuration im using!

[blaze-developer]

If anyone here is using wayland, can you see if you can reproduce the same visual bug im seeing? Whenever I hover over the line graph, or the buttons on the left and right sides, I think there is meant to be a tooltip, but for me it rapidly focuses and unfocuses the window, eventually stopping if i don't move the mouse. It kind of makes the line graph and the side buttons a little unusable.

[nullcubee]

programs.firstdriverstation.enable

I'd argue that it should be under programs.wpilib.firstdriverstation.enable, but either would work imo.

Additionally, the app needs to be a part of the input group in order to have input access. That can be done with the following commands.

sudo chgrp input FirstDriverStation
sudo chmod g+s FirstDriverStation

I'm like 80% sure this is AI-slop bullshit unfortunately, I mentioned this in the initial issue but this doesn't make sense as I'm pretty sure that's not how the input group works. This just sets the access/ownership permissions of the binary, which has nothing to do with whether it can access input stuff or not.

Oh, one more thing, maybe add a note under the driverstation section on the README that states there will be no support from FIRST or WPILib using frc-nix's distribution of the FIRST Driver Station, and that it is not competition legal.

I think this is a good idea, but I think we should make a more general warning for lack of support from WPILib and put that into a separate PR

If anyone here is using wayland ... Whenever I hover over the line graph, or the buttons on the left and right sides, I think there is meant to be a tooltip, but for me it rapidly focuses and unfocuses the window, eventually stopping if i don't move the mouse.

I use Niri, interestingly, I don't seem to get a tooltip at all in the line graph, but this issue sounds like maybe focus-follows-mouse issues or something.

However another issue I have on my Framework 13 is that the scaling isn't correct on the hidpi screen, which may well be an issue or a config program with Niri and xwayland-satellite.

[blaze-developer]

It also uses Avalonia and runs through XWayland. I have xwayland app scaling disabled because of my hidpi screen, and I use environment variables for various graphics API's to scale most desktop applications. (I have 4k monitor)

I have AVALONIA_GLOBAL_SCALE_FACTOR set to a variable (${toString cfg.scaling}).

Heres with the variable enabled:

Heres without the environment variable:

[nullcubee]

I have AVALONIA_GLOBAL_SCALE_FACTOR set to a variable (${toString cfg.scaling}).

ah! thanks, maybe that should be added to the module?

[blaze-developer]

It would depend on what the user wants their scale to be, unless there was a standardized place to put your preferred scale that we could query, I don't think it could be very viable. Also this is very much a compositor configuration / setup thing, as I already had this set for other apps (ryujinx is the reason I learned this existed). Maybe document it as a way to scale Avalonia applications if the scale does not match the rest of their system scale.

[blaze-developer]

Heres a video of the window focus / graphical bug:
https://files.catbox.moe/7u9pqv.mp4

[nullcubee]

Oh I was looking in the wrong place, I don't have that issue at all, yours looks broken for some reason, this is what it looks like for me:

[taciturnaxolotl]

went ahead and removed the module

[blaze-developer]

What functionality does adding the package to the udev list bring?

[taciturnaxolotl]

that lets the hdraw rules get loaded! otherwise, udev doesn't automatically pick up on them

[blaze-developer]

Is it unexpected that my input would work without that modification? Because all I've done is install the package, and all the input, including global estop, and gamepads, is working just fine to my observations.

I'm just trying to make sure we aren't adding unnecessary steps, I'm not sure how reliable the official linux documentation is given what we've seen so far not being exactly accurate.

[taciturnaxolotl]

oh joy; in that case I cease to trust any of their docs

[blaze-developer]

Ill have access to a Systemcore beta device next week, and will check for connectivity / functionality.

[nullcubee]

What functionality does adding the package to the udev list bring?

I had assumed it would allow the program to access keyboard and joysticks globally, without having to be in the input group, but I haven't actually tested that