USB hardware level

[ripleymj]

Per @ChrisMayfield, we should be intentional about requiring the Extension Pack when packaging the VM, as most people won't need it. CS354 may require a better USB controller for moving Kinect data into the VM.

• Remove USB 2.0 from the next image build
• Add a warning/failure if EHCI/xHCI controllers exist during OEM script
• Find a way to warn in the CS354 target of a missing EHCI/xHCI controller
• Create a docs folder, and publish a How to Add Extensions and Upgrade USB markdown file

[laurelmay]

Do we want the EHCI/xHCI warning to be a libnotify notification or did you have something else in mind?

[ripleymj]

In theory, I like that we can do libnotify and move on, but I feel this may be worthy of the subtlety that zenity offers.

[laurelmay]

As far as the warning, I am not sure how to best go about it, so I'm hoping you have something in mind. The best I have though of is:

roles/robot-pkgs/tasks/main.yml

- name: Check for missing USB 2/3 controllers
  shell: lspci | grep -i -e EHCI -e xHCI
  register: lspci_output
  #failed_when: lspci_output.rc != 0
  changed_when: False
- name: Alert missing USB 2/3 controllers
  notify:
      - USB controllers warning
  when: lspci_output.rc != 0

roles/robot-pkgs/handlers/main.yml

- name: USB controllers warning
  command: >-
    zenity --warn --text "USB Controllers missing"
    "In order to effectively connect robots to the VM"
    "ECHI/xHCI controllers need to be installed from"
    "VirtualBox. See <a href='URL'>these instructions</a> for"
    "more information on how to install them"
  become: yes
  become_user: "{{ item.user }}"
  with_items: "{{ real_users }}"

I feel like there is probably a much cleaner way of going about it. It feels dirty that checking the condition and notifying the handler are two separate tasks.

[ripleymj]

That's about it, and I think the two steps are just an Ansible "feature". The unfortunate thing is that HREF in zenity will likely open as root.

[laurelmay]

We'll have to test that. Hopefully if we become_user then it will work out. Though, I am also concerned about how that will play out if there's a user in real_users other than the currently logged-in user and if more than one window comes up.

[ripleymj]

I misread become_user, you're probably right that this is ok. Multiple could get interesting though.

[laurelmay]

For the docs folder, were you hoping for something within the VM (potentially on the desktop), something in jmunixusers/presentations, or something else?

[ripleymj]

I was thinking the presentations repo, possibly with a desktop shortcut.

[laurelmay]

Which of the following would you prefer?

1. Just hijack the existing VM README and change that to point to https://jmunixusers.github.io/presentations/vm and users can go from there
2. Add a task to robot-pkgs that adds a desktop shortcut ("USB Contollers") to the relevant documentation in presentations
3. Create a folder on the desktop called "Documentation" and put all the docs in there. This would require changes to task-shortcuts to create /etc/skel/Desktop/Documentation and robot-pkgs to add the new shortcut

For now I prefer 2, but if we keep adding more docs, 3 might be the better option; although there's nothing stopping us from doing 2 now and 3 later.

[ripleymj]

Concur about 2, with options on 2&3 later.

[laurelmay]

Is there anything left to do for the last two items in the original comment?