Hi Nisimura-san,

the main point is that the configuration you propose is
wrong for the 5100. The numbering needs to change to reflect 
the normal 5100 config of four tty lines on dc0.
as you also note, we need an implementation
which allows line 0 and 1 to be tty lines
on a 5100, and mouse/keyboard on a 3100 and 500/200.

>My driver will have 'line' locator, and lkkbd/vsms/dctty stuff is not
>hardwired on specfic ports.

my point, again, is that line locators are clearly not adequate
om their own.

>        dc0
>           dctty? line 0
>           dctty? line 1

>line 0 and line 1 can be useful for ttys.  Current implementation does
>not allow this.

which makes it very clear why line-based locators are not, on their
own, a solution.  We need the above config on a 5100, and the one you
first posteed (with the tty lines renumbered) on a 3100 -- by default,
anyway. note we have users who use four tty lines on 5000/200s
already.

One possible solution is to have distinct ibus attachments, with 5100s
hardwiring dctty children, and 3100s wiring kbd/mouse.  Another is to
configure both kbd/mouse and tty on line 0 and 1, and embed
model-dependent wiring knowledge in the match routine.  But we also
need a way to override that, for the users who use dongles to convert
the `kbd/mouse' lines to tty lines.  Doing that was a supported
configuration on framebufferless vax/decsystems. If you open the
special devices for dc lines 0 and 1, and set them to 9600n1,
then you can hook up a tty -- provided the kernel did not wire
them up to a framebuffer. That works, now, or did when I last
looked.

hm, (looking anhead) it seems we're getting in sync.
very sorry if this was not clear. I have the flu,
and i'm heading back to bed.