It sounds reasonable to me, but I'd like to clarify your goal.

I was thinking that Keyboard is like a emulation of typing the physical keyboard.
If there is no physical keyboard on DUT, then what are we testing in those cases?
Should we support physical keyboard features on DUTs without physical keyboard, too? Or, should we skip keyboard related tests on those devices by, like, software_deps-ish something (indeed, it's not software, though)?
Or, maybe should we consider virtual keyboard for those DUTs...?

Hmm, good question. I think that Chromeboxes are the main case that I'm thinking of here. Using the virtual keyboard is probably reasonable for tablets, but since external keyboards are the typical input devices on Chromeboxes, it would be good to be able to simulate them in tests.

Re #2: Thank you for explanation, and, yes, that makes sense.

I think that we probably just need to do what libevdev_set_fd in https://cgit.freedesktop.org/libevdev/tree/libevdev/libevdev.c does, i.e. perform various ioctls.

I'm working on this now. It seems easier than I expected.

I don't know if it makes sense to give callers the ability to choose which device to use, whether to create a new device, etc. To start out with, I may just make input.Keyboard and friends open a physical device if one already exists and create a temporary fake device otherwise.

if you already figured it out how to do it, great! (I'd like to know if it would be possible to support a virtual touchscreen device as well... I don't need it now, but I'd like to know).

If not, it should be possible to create a virtual keyboard using libusb, and HID profile that implements keyboard on top of it. Although not sure whether we want to add the libusb dependency.

I think that the path that libevdev_uinput_create_from_device() takes when passed LIBEVDEV_UINPUT_OPEN_MANAGED is basically what we need to do: https://cgit.freedesktop.org/libevdev/tree/libevdev/libevdev-uinput.c#n357

I'll leave the door open for creating touchscreen devices, but will probably just focus on keyboards initially. I think that process for touchscreens would be similar (albeit possibly with some more ioctls to set additional properties).

derat@ thanks for the tip. good to know it works using libevent. much better than using libusb.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/3222c12dcadf7f256017e920c79873cb39506328

commit 3222c12dcadf7f256017e920c79873cb39506328
Author: Daniel Erat <derat@chromium.org>
Date: Tue Jan 15 10:54:47 2019

tast-tests: Make input package get device nodes from sysfs.

Make the input package get device nodes from sysfs rather
than parsing them from the "Handlers" list in
/proc/bus/input/devices. This will make it easier to get
virtual devices' nodes in a future change.

Also update the devInfo struct to store devices' physical
paths. This will be used to identify virtual devices in a
future change.

BUG=chromium:915965
TEST=updated unit tests, also manually verified that
     example.Keyboard is still able to inject key events

Change-Id: Ic2e448b2865c5798ec3d5080fb66e5aec197af0e
Reviewed-on: https://chromium-review.googlesource.com/1407134
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Shuhei Takahashi <nya@chromium.org>

[modify] https://crrev.com/3222c12dcadf7f256017e920c79873cb39506328/src/chromiumos/tast/local/input/keyboard.go
[modify] https://crrev.com/3222c12dcadf7f256017e920c79873cb39506328/src/chromiumos/tast/local/input/touch.go
[modify] https://crrev.com/3222c12dcadf7f256017e920c79873cb39506328/src/chromiumos/tast/local/input/device.go
[modify] https://crrev.com/3222c12dcadf7f256017e920c79873cb39506328/src/chromiumos/tast/local/input/device_test.go