[Arm-netbook] Warning about tablets/netbooks with detachable keyboards

[dumblob]

Hi Luke,

just a tiny note about your mentions of a "tablet/netbook" in
https://www.crowdsupply.com/eoma68/micro-desktop/updates/latest-from-shenzhen
.

In case you're planning to have the keyboard detachable (even worse if this
detachable piece should have some connectors like USB), think of it twice
as per experience of many users of different such tablets/netbooks (youtube
is full of such reviews), the detachable connection is very fragile
(because the detachable design requires a shallow or rather just "touching"
connection in contrast to "sliding" deeper connectors like USB).

Therefore there will be a need for advanced SW means (from Linux kernel
through all daemons up to GUI) to cope with interrupted keyboard input,
interrupted USB communication, etc.). I'm though not aware of any such
comprehensive solutions, so this will most likely become very painful and
will stay so forever if introduced.

Keep going,

-- Jan

[Albert ARIBAUD]

Bonjour,

Le Tue, 13 Dec 2016 17:46:11 +0000

heh im mostly sure luke had no desire for the keyboard to be modular,
as keyboards where such a nightmere. the work for french keyboard
firmware was for the same model but diff labels and key combos
basicly. as i understand it.
could be wrong but i think this is the case.

Broadly right. ISTR some rare keys might exist in FR that don't in US
(or the other way around), but essentially yes, FR vs US is a label and
combination issue.

However, that's for the laptop, which does not have a detachable
keyboard anyway, so is not affected indeed by any issue raised by the
OP.

Speaking of which, only the drivers should be affected by detaching /
attaching a detachable keyboard, and precisely, the drivers should
handle things so that upper layers don't need to care about the
keyboard attached/detached state (except very specific parts of the UI,
e.g. to show the detached/attached state and/or pop up a software
keyboard when the HW one is not here and keyboard input is needed). Most
certainly "all daemons up to GUI" should not be involved IMO.

_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

Amicalement,

[dumblob]

Hi Albert,

Speaking of which, only the drivers should be affected by detaching /

Post by Albert ARIBAUD
attaching a detachable keyboard, and precisely, the drivers should
handle things so that upper layers don't need to care about the
keyboard attached/detached state (except very specific parts of the UI,
e.g. to show the detached/attached state and/or pop up a software
keyboard when the HW one is not here and keyboard input is needed). Most
certainly "all daemons up to GUI" should not be involved IMO.

Actually, not only driver needs to know it. Kernel needs to correctly pass
the info about what has happened to HAL (udev, etc.), then daemons reacting
to attaching/detaching devices (dbus, *bus, systemd, running terminals,
PAM, etc.) up to GUI (window manager must not reset the layout; all input
methods like SCIM/IBus/uim must preserve all pressed states etc.; mappings
of different long-running applications like widgets or icons in tray should
keep their state; user shortcuts must not get lost; running applications
should not reset any input streams to not interrupt the current
functionality, etc.).

All these have to handle the interruptions in a way, that they exactly (!)
set the full device state back to the state before interruption. They also
need to support these interruptions coming very quickly consecutively (e.g.
each milisecond).

Basically such interruption demands a full hot swap functionality, which is
basically not present anywhere in the stack I described above (yeah, 99.99%
daemons and applications count on the fact, that the initial state will not
change during their runtime).

It's really extremely frustrating when an old USB connector looses contact
for a milisecond and my external keyboard gets redected and all the
settings are totally lost (in terminal a different keyboard and without my
key bindings - which might be impossible to manually reset because of the
need of root permissions; the same in X except for the root permissions;
the same with all running applications; the same everywhere). An extreme
case are security modules (e.g. YubiKey) or security SW demanding
uninterrupted connection of a certain device (due to possible MiM attacks
etc.).

Just my 2 cents from real world.

-- Jan

[Albert ARIBAUD]

Bonjour,

Le Wed, 14 Dec 2016 20:23:39 +0100

Post by dumblob
Hi Albert,
Speaking of which, only the drivers should be affected by detaching /

Post by Albert ARIBAUD
attaching a detachable keyboard, and precisely, the drivers should
handle things so that upper layers don't need to care about the
keyboard attached/detached state (except very specific parts of the
UI, e.g. to show the detached/attached state and/or pop up a
software keyboard when the HW one is not here and keyboard input is
needed). Most certainly "all daemons up to GUI" should not be
involved IMO.

Actually, not only driver needs to know it. Kernel needs to correctly
pass the info about what has happened to HAL (udev, etc.), then
daemons reacting to attaching/detaching devices (dbus, *bus, systemd,
running terminals, PAM, etc.) up to GUI (window manager must not
reset the layout; all input methods like SCIM/IBus/uim must preserve
all pressed states etc.; mappings of different long-running
applications like widgets or icons in tray should keep their state;
user shortcuts must not get lost; running applications should not
reset any input streams to not interrupt the current functionality,
etc.).

I am far from convinced that all of this is sensitive to whether one
keyboard was plugged or unplugged from the system. Why would icons
in the tray be affected by the number of keyboards connected to the
computer, for instance?

Post by dumblob
All these have to handle the interruptions in a way, that they
exactly (!) set the full device state back to the state before
interruption. They also need to support these interruptions coming
very quickly consecutively (e.g. each milisecond).
Basically such interruption demands a full hot swap functionality,
which is basically not present anywhere in the stack I described
above (yeah, 99.99% daemons and applications count on the fact, that
the initial state will not change during their runtime).

I am having a hard time trying to make sense of what you're saying,
which is frustrating, as I've been doing embedded development for more
that 20 years. For instance:

- I am surprised that all of a sudden, all SW in a computer has to
handle interruptions. In my time (which extends to just about a few
days ago), only drivers did. "Driver" is basically the name we give
to thoses pieces of SW which handle interrupts (and talk to HW and do
DMA requests and...)

- Nor did any of the systems I worked, and still work on, require that
the full system state be saved and restored on interrupts; in fact,
if they did completely save and restore their state, they interrupts
would have no effect whatsoever, which would be a pity. Granted,
interrupt handlers must save whatever CPU resources they use, and
schedulers must do the same with task states; but that's hardly a
concern outside of these two cases.

- Finally, the daemons in my time /did/ expect their state to change all
the time. They actually were /intended/ to change state, in carefully
designed ways; a daemon executing in an immutable environment would
have little utility.

Joke apart, I really don't agree with your description of systems as
holistic constructions which would be affected throughout by any event
happening in a device (except, precisely, from a holistic viewpoint,
which I like in Dirk Gently, but carefully avoid in my day-to-day
embedded developing and debugging). Mastering complex SW is precisely
about avoiding that all things be interconnected (alright, not *only*
about that, but about that too).

Post by dumblob
It's really extremely frustrating when an old USB connector looses
contact for a milisecond and my external keyboard gets redected and
all the settings are totally lost (in terminal a different keyboard
and without my key bindings - which might be impossible to manually
reset because of the need of root permissions; the same in X except
for the root permissions; the same with all running applications; the
same everywhere).

I don't know what is the setup on which you encounter these issues; on
mine, I can connect and disconnect keyboards at will, with nothing even
so much as flipping a bit when I do, and my keyboards don't even lose
their French layout :) -- same goes for USB devices which need to get
their firmware uploaded through USB; granted, every time I unplug and
replug them, thy take time to get their firmware /again/, and yes,
trying to use a video capture device won't work if you unplug it right
in the middle of it, but you can hardly expect otherwise, and it's only
logical that plugging it back won't fix the overall problem.

Post by dumblob
An extreme case are security modules (e.g. YubiKey)
or security SW demanding uninterrupted connection of a certain device
(due to possible MiM attacks etc.).

As you say, this is an extreme example. In fact, it is precisely an
example of a setup where continuous connection is laid out a priori as
a /requirement/; no wonder, then, that discontinuity of connection is
not supported.

But not all setups require continuous connection, far from that, and
for keyboards particularly, disconnection and reconnection scenarios
are known and handled cleanly without all application code needing to
be written specially for that.

Post by dumblob
Just my 2 cents from real world.

You should be careful with the way you express yourself: one could be
led to believe that here you are implying I would not know of the real
world whereas you do, and that this implied difference would make my
opinion less worthy than yours. But of course you are not implying
that, since you do no know me at all, right ?

So let's avoid anyone getting false ideas, and to that effect, let's
stay away from hypothetically real vs hypothetically unreal worlds, and
let's just keep to technical discussion with technical and precise
arguments. Shall we?

Post by dumblob
-- Jan

Amicalement,

[dumblob]

Hi Albert,

I am far from convinced that all of this is sensitive to whether one

Post by Albert ARIBAUD
keyboard was plugged or unplugged from the system. Why would icons
in the tray be affected by the number of keyboards connected to the
computer, for instance?

because it's an unwritten expectation in HIGs (Human Interface Guidelines),
that tray icons show and react to events happening close to user
(physically, theoretically). Hence (un)plugging devices inclusive. Unwanted
interruptions are then interpreted as unexpected (un)plugging.

I am having a hard time trying to make sense of what you're saying,

Post by Albert ARIBAUD
which is frustrating, as I've been doing embedded development for more
- I am surprised that all of a sudden, all SW in a computer has to
handle interruptions. In my time (which extends to just about a few
days ago), only drivers did. "Driver" is basically the name we give
to thoses pieces of SW which handle interrupts (and talk to HW and do
DMA requests and...)
- Nor did any of the systems I worked, and still work on, require that
the full system state be saved and restored on interrupts; in fact,
if they did completely save and restore their state, they interrupts
would have no effect whatsoever, which would be a pity. Granted,
interrupt handlers must save whatever CPU resources they use, and
schedulers must do the same with task states; but that's hardly a
concern outside of these two cases.
- Finally, the daemons in my time /did/ expect their state to change all
the time. They actually were /intended/ to change state, in carefully
designed ways; a daemon executing in an immutable environment would
have little utility.

It's irrelevant who we are and what we do. The fact is, that in case of
unwanted interruptions, the state shall be 100% preserved. Which is
currently not implemented in any layer of the common Linux and BSD systems
except sometimes for the driver.

I don't know what is the setup on which you encounter these issues; on

Post by Albert ARIBAUD
mine, I can connect and disconnect keyboards at will, with nothing even
so much as flipping a bit when I do, and my keyboards don't even lose
their French layout :) -- same goes for USB devices which need to get
their firmware uploaded through USB; granted, every time I unplug and
replug them, thy take time to get their firmware /again/, and yes,
trying to use a video capture device won't work if you unplug it right
in the middle of it, but you can hardly expect otherwise, and it's only
logical that plugging it back won't fix the overall problem.

The whole thread is about unwanted interruptions, not user-initiated. Refer
to the the groups of issues and several specific program names affected by
unwanted interruptions as mentioned in my previous email to get an idea
what for a mainstream setup it might be.

Post by Albert ARIBAUD

Post by dumblob
An extreme case are security modules (e.g. YubiKey)
or security SW demanding uninterrupted connection of a certain device
(due to possible MiM attacks etc.).

As you say, this is an extreme example. In fact, it is precisely an
example of a setup where continuous connection is laid out a priori as
a /requirement/; no wonder, then, that discontinuity of connection is
not supported.

And therefore we need to make absolutely sure, that all detachable "hubs"
will prevent unwanted interruptions.

Post by Albert ARIBAUD
Just my 2 cents from real world.
You should be careful with the way you express yourself: one could be
led to believe that here you are implying I would not know of the real
world whereas you do, and that this implied difference would make my
opinion less worthy than yours. But of course you are not implying
that, since you do no know me at all, right ?
So let's avoid anyone getting false ideas, and to that effect, let's
stay away from hypothetically real vs hypothetically unreal worlds, and
let's just keep to technical discussion with technical and precise
arguments. Shall we?

Maybe English is really still not the language of the world as the meaning
of "real world" is being undeniably confused with "real world without
everything Albert ARIBAUD came across".

Kind regards,

-- Jan

[Albert ARIBAUD]

Bonjour,

Le Wed, 14 Dec 2016 21:49:13 +0100

Post by dumblob
Hi Albert,
I am far from convinced that all of this is sensitive to whether one

Post by Albert ARIBAUD
keyboard was plugged or unplugged from the system. Why would icons
in the tray be affected by the number of keyboards connected to the
computer, for instance?

because it's an unwritten expectation in HIGs (Human Interface
Guidelines), that tray icons show and react to events happening close
to user (physically, theoretically). Hence (un)plugging devices
inclusive. Unwanted interruptions are then interpreted as unexpected
(un)plugging.

Can you provide support for these statements please?

Post by dumblob
I am having a hard time trying to make sense of what you're saying,

Post by Albert ARIBAUD
which is frustrating, as I've been doing embedded development for
- I am surprised that all of a sudden, all SW in a computer has to
handle interruptions. In my time (which extends to just about a
few days ago), only drivers did. "Driver" is basically the name we
give to thoses pieces of SW which handle interrupts (and talk to HW
and do DMA requests and...)
- Nor did any of the systems I worked, and still work on, require
that the full system state be saved and restored on interrupts; in
fact, if they did completely save and restore their state, they
interrupts would have no effect whatsoever, which would be a pity.
Granted, interrupt handlers must save whatever CPU resources they
use, and schedulers must do the same with task states; but that's
hardly a concern outside of these two cases.
- Finally, the daemons in my time /did/ expect their state to
change all the time. They actually were /intended/ to change state,
in carefully designed ways; a daemon executing in an immutable
environment would have little utility.

It's irrelevant who we are and what we do. The fact is, that in case
of unwanted interruptions, the state shall be 100% preserved. Which is
currently not implemented in any layer of the common Linux and BSD
systems except sometimes for the driver.

Sorry, that makes absolutely zero sense.

Post by dumblob
I don't know what is the setup on which you encounter these issues; on

Post by Albert ARIBAUD
mine, I can connect and disconnect keyboards at will, with nothing
even so much as flipping a bit when I do, and my keyboards don't
even lose their French layout :) -- same goes for USB devices which
need to get their firmware uploaded through USB; granted, every
time I unplug and replug them, thy take time to get their
firmware /again/, and yes, trying to use a video capture device
won't work if you unplug it right in the middle of it, but you can
hardly expect otherwise, and it's only logical that plugging it
back won't fix the overall problem.

The whole thread is about unwanted interruptions, not user-initiated.

Actually, the whole thread is about disconnectable keyboards.

Post by dumblob
Refer to the the groups of issues and several specific program names
affected by unwanted interruptions as mentioned in my previous email
to get an idea what for a mainstream setup it might be.

You are trying to prove your point by stating your point. This, a
tautology, amounts to no proof at all.

Post by dumblob

Post by Albert ARIBAUD

Post by dumblob
An extreme case are security modules (e.g. YubiKey)
or security SW demanding uninterrupted connection of a certain
device (due to possible MiM attacks etc.).

As you say, this is an extreme example. In fact, it is precisely an
example of a setup where continuous connection is laid out a priori
as a /requirement/; no wonder, then, that discontinuity of
connection is not supported.

And therefore we need to make absolutely sure, that all detachable
"hubs" will prevent unwanted interruptions.

Only in scenarios which lay out continuity as a requirement, which is
rarely if ever a valid requirement, and certainly not one envisioned
here -- as you actually have acknowledged to Luke, BTW.

Post by dumblob

Post by Albert ARIBAUD
Just my 2 cents from real world.
You should be careful with the way you express yourself: one could
be led to believe that here you are implying I would not know of
the real world whereas you do, and that this implied difference
would make my opinion less worthy than yours. But of course you are
not implying that, since you do no know me at all, right ?
So let's avoid anyone getting false ideas, and to that effect, let's
stay away from hypothetically real vs hypothetically unreal worlds,
and let's just keep to technical discussion with technical and
precise arguments. Shall we?

Maybe English is really still not the language of the world as the
meaning of "real world" is being undeniably confused with "real world
without everything Albert ARIBAUD came across".

Oh, look, you're doing ad hominems as well as projecting your own
shortcoming on your contradictor!

OK, joke has lasted enough for me (and, more important, for the rest of
the list I suspect). Let me know when you decide to switch from
counter-productive rhetorics to actually productive technical
discussion.

Post by dumblob
Kind regards,
-- Jan

Amicalement,

[dumblob]

1) follow http://www.wikihow.com/Change-Keyboard-Layout-in-Ubuntu

2) switch to the newly added layout of your choice

3) simulate unwanted interruption (e.g. detach internal or external
physical keyboard and reattach it)

4) enjoy a different layout than the one you switched to in step 2

5) try to correct this wrong behavior in a way, that it won't appear under
any circumstances in all mainstream Linux distributions and BSDs and others
(and I'm not talking only about X, but also about text and framebuffer
consoles, Wayland, and Mir); of course

6) tell us all in this list what everything in the whole stack needed to be
patched, how much, and why exactly

Post by Albert ARIBAUD
Bonjour,
Le Wed, 14 Dec 2016 21:49:13 +0100

Post by dumblob
Hi Albert,
I am far from convinced that all of this is sensitive to whether one

Post by Albert ARIBAUD
keyboard was plugged or unplugged from the system. Why would icons
in the tray be affected by the number of keyboards connected to the
computer, for instance?

because it's an unwritten expectation in HIGs (Human Interface
Guidelines), that tray icons show and react to events happening close
to user (physically, theoretically). Hence (un)plugging devices
inclusive. Unwanted interruptions are then interpreted as unexpected
(un)plugging.

Can you provide support for these statements please?

Post by dumblob
I am having a hard time trying to make sense of what you're saying,

Post by Albert ARIBAUD
which is frustrating, as I've been doing embedded development for
- I am surprised that all of a sudden, all SW in a computer has to
handle interruptions. In my time (which extends to just about a
few days ago), only drivers did. "Driver" is basically the name we
give to thoses pieces of SW which handle interrupts (and talk to HW
and do DMA requests and...)
- Nor did any of the systems I worked, and still work on, require
that the full system state be saved and restored on interrupts; in
fact, if they did completely save and restore their state, they
interrupts would have no effect whatsoever, which would be a pity.
Granted, interrupt handlers must save whatever CPU resources they
use, and schedulers must do the same with task states; but that's
hardly a concern outside of these two cases.
- Finally, the daemons in my time /did/ expect their state to
change all the time. They actually were /intended/ to change state,
in carefully designed ways; a daemon executing in an immutable
environment would have little utility.

It's irrelevant who we are and what we do. The fact is, that in case
of unwanted interruptions, the state shall be 100% preserved. Which is
currently not implemented in any layer of the common Linux and BSD
systems except sometimes for the driver.

Sorry, that makes absolutely zero sense.

Post by dumblob
I don't know what is the setup on which you encounter these issues; on

Post by Albert ARIBAUD
mine, I can connect and disconnect keyboards at will, with nothing
even so much as flipping a bit when I do, and my keyboards don't
even lose their French layout :) -- same goes for USB devices which
need to get their firmware uploaded through USB; granted, every
time I unplug and replug them, thy take time to get their
firmware /again/, and yes, trying to use a video capture device
won't work if you unplug it right in the middle of it, but you can
hardly expect otherwise, and it's only logical that plugging it
back won't fix the overall problem.

The whole thread is about unwanted interruptions, not user-initiated.

Actually, the whole thread is about disconnectable keyboards.

Post by dumblob
Refer to the the groups of issues and several specific program names
affected by unwanted interruptions as mentioned in my previous email
to get an idea what for a mainstream setup it might be.

You are trying to prove your point by stating your point. This, a
tautology, amounts to no proof at all.

Post by dumblob

Post by Albert ARIBAUD

Post by dumblob
An extreme case are security modules (e.g. YubiKey)
or security SW demanding uninterrupted connection of a certain
device (due to possible MiM attacks etc.).

As you say, this is an extreme example. In fact, it is precisely an
example of a setup where continuous connection is laid out a priori
as a /requirement/; no wonder, then, that discontinuity of
connection is not supported.

And therefore we need to make absolutely sure, that all detachable
"hubs" will prevent unwanted interruptions.

Only in scenarios which lay out continuity as a requirement, which is
rarely if ever a valid requirement, and certainly not one envisioned
here -- as you actually have acknowledged to Luke, BTW.

Post by dumblob

Post by Albert ARIBAUD
Just my 2 cents from real world.
You should be careful with the way you express yourself: one could
be led to believe that here you are implying I would not know of
the real world whereas you do, and that this implied difference
would make my opinion less worthy than yours. But of course you are
not implying that, since you do no know me at all, right ?
So let's avoid anyone getting false ideas, and to that effect, let's
stay away from hypothetically real vs hypothetically unreal worlds,
and let's just keep to technical discussion with technical and
precise arguments. Shall we?

Maybe English is really still not the language of the world as the
meaning of "real world" is being undeniably confused with "real world
without everything Albert ARIBAUD came across".

Oh, look, you're doing ad hominems as well as projecting your own
shortcoming on your contradictor!
OK, joke has lasted enough for me (and, more important, for the rest of
the list I suspect). Let me know when you decide to switch from
counter-productive rhetorics to actually productive technical
discussion.

Post by dumblob
Kind regards,
-- Jan

Amicalement,
--
Albert.

[Luke Kenneth Casson Leighton]

Post by dumblob
1) follow http://www.wikihow.com/Change-Keyboard-Layout-in-Ubuntu
2) switch to the newly added layout of your choice
3) simulate unwanted interruption (e.g. detach internal or external
physical keyboard and reattach it)
4) enjoy a different layout than the one you switched to in step 2
5) try to correct this wrong behavior in a way, that it won't appear under
any circumstances in all mainstream Linux distributions and BSDs and others
(and I'm not talking only about X, but also about text and framebuffer
consoles, Wayland, and Mir); of course
6) tell us all in this list what everything in the whole stack needed to be
patched, how much, and why exactly

'
if it's a known problem that's simply down to someone, somewhere, in
the GNU/Linux OS software stack not getting their act together, or if
it's something strange such as changing the keyboard layout in
software as opposed to plugging in the *correct* keyboard with a
default hardware layout... then it's well beyond the scope of this
list.

the reasons for that are as follows:

(1) the purpose of this project is to ethically develop eco-conscious
hardware, riding off the back of as much that is already "mass-volume"
as possible. components, OSes, user-bases, and so on, with a
bootstrapping method to get there.

(2) the project is not yet at the point where it's large enough in
scope to have spare funds available to go funding arbitrary software
projects, and even if it did, from experience it's been learned that
providing funding to software libre projects is often *detrimental*...
so would not be a good idea anyway. instead, it would be better to
work *with* them - raise bugreports - and let them get on with it.

so.

can i suggest, if you have discovered a problem with a particular
GNU/Linux distribution, especially if you have a hardware-related
repro case (which you appear to have, above), to report it via their
bugtracker. with good bugreports, clearly written, good developers
tend to appreciate that, and, as long as they have funding and/or
time, tend to get to them in good time.

if however you *don't* report it - and i will not be doing so (i have
too much else to do, i have to focus on hardware) - it will *remain*
broken, indefinitely... or until someone else notices and reports it.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne

[dumblob]

Hi Luke,

I'm aware of all what you mentioned. The repro case is solely for Albert.

By the way I'm working (including bug reporting) a lot in this domain of
user input/output with regards to IT devices (as you may have already
noticed from my github page showing a tiny fraction of it). But it's a very
long haul. Therefore this warning thread.

Kind regards,

-- Jan

[Luke Kenneth Casson Leighton]

Post by dumblob
Hi Luke,
I'm aware of all what you mentioned. The repro case is solely for Albert.

i did say "be nice", which was by way of being a warning. the way
you wrote it was barbed.

Post by dumblob
By the way I'm working (including bug reporting) a lot in this domain of
user input/output with regards to IT devices (as you may have already
noticed from my github page showing a tiny fraction of it). But it's a very
long haul. Therefore this warning thread.

out of scope for this project. users changing layouts then having
problems because of it, and having unreliable USB connectors is
definitely out of scope for this project.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta

[Luke Kenneth Casson Leighton]

Post by dumblob
Hi Luke,
I'm aware of all what you mentioned. The repro case is solely for Albert.

.... who is unlikely to respond to you at all until you apologise,
both for being sarcastic towards him and also utilising this list to
send barbed messages at him (in the form of a "repro case"), and
taking up about a thousand other people's time in the process.

you've provided valuable insights and information in one specialist
area, but so too do other people also provide valuable insights and
information. when i said "play nice" it was by way of being a
warning.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Luke Kenneth Casson Leighton]

Post by dumblob
Maybe English is really still not the language of the world as the meaning
of "real world" is being undeniably confused with "real world without
everything Albert ARIBAUD came across".

OI! play nice.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@

[c***@sasktel.net]

Post by Albert ARIBAUD
Bonjour,
Le ~, 13 Dec 2016 17:46:11 +0000

heh im mostly sure luke had no desire for the keyboard to be modular,
as keyboards where such a nightmere. the work for french keyboard
firmware was for the same model but diff labels and key combos
basicly. as i understand it.
could be wrong but i think this is the case.

Broadly right. ISTR some rare keys might exist in FR that don't in US
(or the other way around), but essentially yes, FR vs US is a label and
combination issue.

Maybe you are referring to something else or more-specific, but as far as I
understand-
Common international key-boards have 1 more key (105 if full-size) than common
US-key-boards (104). (Other differences can be placement, currency-sign available,
and other symbols or special letters.)
The additional key can even be found on a lap-top which uses a condensed layout
without separate number-pad (and with only one key for "Super"/"Meta"/"Win",
grumble grumble), and is otherwise the US-lay-out.
The additional key is normally just left of the bottom row of letters.
Sample labels on it are double angle-quoters << >> or (as a second key with) |
and \
It looks like lay-outs of US plus additional key, are used by the Romanian
programmers' lay-out, and the Slovak QWERTY-lay-out
(https://en.wikipedia.org/wiki/QWERTY).

It is nice to have the additional key, for non-default key-bindings
("shortcuts", "hotkeys"), and for non-default lay-outs which are provided by
"software".

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne

[Luke Kenneth Casson Leighton]

Post by dumblob
Hi Luke,
just a tiny note about your mentions of a "tablet/netbook" in
https://www.crowdsupply.com/eoma68/micro-desktop/updates/latest-from-shenzhen

i do wish that crowdsupply could provide on-post comments, but then
they'd have to monitor them.

Post by dumblob
In case you're planning to have the keyboard detachable (even worse if this
detachable piece should have some connectors like USB), think of it twice
as per experience of many users of different such tablets/netbooks (youtube
is full of such reviews), the detachable connection is very fragile
(because the detachable design requires a shallow or rather just "touching"
connection in contrast to "sliding" deeper connectors like USB).

ok. first thing: have you heard of the alwaysinnovating touchbook?
it was the world's very first hybrid netbook / tablet. most people
don't even know it exists, sadly. as a monolithic design it would
ordinarily have a lifespan of about... six to eight months, but
because it was targetted at linux users that was actually
about...eighteen months / two years. what killed it was the use of a
720mhz ARM Cortex A8, RAM limited to 512mb... no means of upgrading
except a whopping $50k for replacing the entire main PCB.

anyway: the casework was extremely robust, with the
keyboard+extra-battery portion having inch-long "arms" at the sides to
securely and firmly hold the main tablet part in place... in a
standard USB socket.

you have to bear in mind that i'm being quite realistic about this
whole exercise: if i can't design it to be robust in PLA with a
standard mendel 3D printer, and i can't get off-the-shelf generic
parts that are commonly available from multiple suppliers in huaqiang
rd, futian district, shenzhen, china, it ain't going in.

so whilst what you're seeing is complaints based on a
fight-to-the-minimum (in terms of both thickness and price), i will be
designing stuff that's "chunky", realistically maintainable by a
lego-mindsetted individual, and built to last.

therefore, i will *NOT* be attempting to replicate the existing slew
of magnetic catches and so on, apart from anything i won't be able to
get hold of them as they will have been custom-designed for specific
OEMs.

i _do_ have a background in physics and mathematics which gives me
some mechanical design aptitude :)

Post by dumblob
Therefore there will be a need for advanced SW means (from Linux kernel
through all daemons up to GUI) to cope with interrupted keyboard input,
interrupted USB communication, etc.). I'm though not aware of any such
comprehensive solutions, so this will most likely become very painful and
will stay so forever if introduced.

USB. simple as that. problem goes away. USB's already designed to
be interruptable. people unplug keyboards and mice all the time. the
linux kernel's had USB support since forever. i don't expect there to
be any software problems at all.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attach

[dumblob]

Hi Luke,

thanks for flashing a light on that. I'm glad you're staying with USB.

I think this thread is answered.

-- Jan

Post by dumblob

Post by dumblob
Hi Luke,
just a tiny note about your mentions of a "tablet/netbook" in
https://www.crowdsupply.com/eoma68/micro-desktop/updates/

latest-from-shenzhen
i do wish that crowdsupply could provide on-post comments, but then
they'd have to monitor them.

Post by dumblob
In case you're planning to have the keyboard detachable (even worse if

this

Post by dumblob
detachable piece should have some connectors like USB), think of it twice
as per experience of many users of different such tablets/netbooks

(youtube

Post by dumblob
is full of such reviews), the detachable connection is very fragile
(because the detachable design requires a shallow or rather just

"touching"

Post by dumblob
connection in contrast to "sliding" deeper connectors like USB).

ok. first thing: have you heard of the alwaysinnovating touchbook?
it was the world's very first hybrid netbook / tablet. most people
don't even know it exists, sadly. as a monolithic design it would
ordinarily have a lifespan of about... six to eight months, but
because it was targetted at linux users that was actually
about...eighteen months / two years. what killed it was the use of a
720mhz ARM Cortex A8, RAM limited to 512mb... no means of upgrading
except a whopping $50k for replacing the entire main PCB.
anyway: the casework was extremely robust, with the
keyboard+extra-battery portion having inch-long "arms" at the sides to
securely and firmly hold the main tablet part in place... in a
standard USB socket.
you have to bear in mind that i'm being quite realistic about this
whole exercise: if i can't design it to be robust in PLA with a
standard mendel 3D printer, and i can't get off-the-shelf generic
parts that are commonly available from multiple suppliers in huaqiang
rd, futian district, shenzhen, china, it ain't going in.
so whilst what you're seeing is complaints based on a
fight-to-the-minimum (in terms of both thickness and price), i will be
designing stuff that's "chunky", realistically maintainable by a
lego-mindsetted individual, and built to last.
therefore, i will *NOT* be attempting to replicate the existing slew
of magnetic catches and so on, apart from anything i won't be able to
get hold of them as they will have been custom-designed for specific
OEMs.
i _do_ have a background in physics and mathematics which gives me
some mechanical design aptitude :)

Post by dumblob
Therefore there will be a need for advanced SW means (from Linux kernel
through all daemons up to GUI) to cope with interrupted keyboard input,
interrupted USB communication, etc.). I'm though not aware of any such
comprehensive solutions, so this will most likely become very painful and
will stay so forever if introduced.

USB. simple as that. problem goes away. USB's already designed to
be interruptable. people unplug keyboards and mice all the time. the
linux kernel's had USB support since forever. i don't expect there to
be any software problems at all.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[c***@sasktel.net]

Post by Luke Kenneth Casson Leighton

Post by dumblob
Hi Luke,
In case you're planning to have the keyboard detachable (even worse if this
detachable piece should have some connectors like USB), think of it twice
as per experience of many users of different such tablets/netbooks (youtube
is full of such reviews), the detachable connection is very fragile
(because the detachable design requires a shallow or rather just "touching"
connection in contrast to "sliding" deeper connectors like USB).

ok. first thing: have you heard of the alwaysinnovating touchbook?
it was the world's very first hybrid netbook / tablet. most people
don't even know it exists, sadly. as a monolithic design it would
ordinarily have a lifespan of about... six to eight months, but
because it was targetted at linux users that was actually
about...eighteen months / two years. what killed it was the use of a
720mhz ARM Cortex A8, RAM limited to 512mb... no means of upgrading
except a whopping $50k for replacing the entire main PCB.
anyway: the casework was extremely robust, with the
keyboard+extra-battery portion having inch-long "arms" at the sides to
securely and firmly hold the main tablet part in place... in a
standard USB socket.

The "ThinkPad"-series had (or has) convertibles ("X41 Tablet", "X60 Tablet,
Helix) [1].
(By the way, the X60-convertible is listed as supported by "libreboot" [2].)
This line of computers seems to have been distinctively-sturdy. And the
X60-convertible was said to have "signature ~ bulletproof build quality" and be
"more ~ sturdy than any ultralight convertible we have used." [3].
So maybe how they JOINed the key-board to the screen, was more sturdy than
other often-problematic "implementations". (But I have neither seen nor read HOW
Lenovo connected the two parts.)
As far as I see, there are two separate concerns- (1) the data-connection (USB
here, I guess Luke wrote) (the concern of the original post), and (2) how the
screen and the key-board are held (joined) together (a 2nd thing discussed in this
context, like the arms mentioned above).

[1] https://en.wikipedia.org/wiki/ThinkPad_X_Series
if you press ctrl f and look for "conver"
[2] https://libreboot.org/docs/hcl/index.html#supported_laptops_x86intel
[3] http://www.laptopmag.com/reviews/laptops/lenovo-thinkpad-x60-tablet

Post by Luke Kenneth Casson Leighton
you have to bear in mind that i'm being quite realistic about this
whole exercise: if i can't design it to be robust in PLA with a
standard mendel 3D printer, and i can't get off-the-shelf generic
parts that are commonly available from multiple suppliers in huaqiang
rd, futian district, shenzhen, china, it ain't going in.
so whilst what you're seeing is complaints based on a
fight-to-the-minimum (in terms of both thickness and price), i will be
designing stuff that's "chunky", realistically maintainable by a
lego-mindsetted individual, and built to last.
therefore, i will *NOT* be attempting to replicate the existing slew
of magnetic catches and so on, apart from anything i won't be able to
get hold of them as they will have been custom-designed for specific
OEMs.
i _do_ have a background in physics and mathematics which gives me
some mechanical design aptitude :)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo

[m***@gmail.com]

Post by c***@sasktel.net
The "ThinkPad"-series had (or has) convertibles ("X41 Tablet", "X60
Tablet, Helix) [1].
(By the way, the X60-convertible is listed as supported by "libreboot" [2].)
This line of computers seems to have been distinctively-sturdy. And
the X60-convertible was said to have "signature ~ bulletproof build
quality" and be "more ~ sturdy than any ultralight convertible we have
used." [3].
So maybe how they JOINed the key-board to the screen, was more sturdy
than other often-problematic "implementations". (But I have neither seen
nor read HOW Lenovo connected the two parts.)
As far as I see, there are two separate concerns- (1) the
data-connection (USB here, I guess Luke wrote) (the concern of the original
post), and (2) how the screen and the key-board are held (joined) together
(a 2nd thing discussed in this context, like the arms mentioned above).

The X41 and X60 do not have detachable screens. The screens are on a hinge.
The hinge is propriety hardware produced in 'small' volumes. Tailor made
for these laptops.

The Helix is detachable probably uses a tailor made connector produced in
'small' volumes.

By small I mean a big volume enough for production of the
laptops/convertables/tablets and some stock as replacement parts or batch
filling.

The EOMA products are based on "ominous parts". Parts not made for specific
products but used in many. Luke recently found that one selected part did
not meet that criteria and had to change the PCB to fit a more ominously
available part.

This makes it the "EOMA" products sustainable and relatively cheap.

The are a few options as far as I see.

1. Magnetic connectors, like the now dropped apple mag-safe(tm) connector.
It might work as there are "Chinese" knockoffs for micro-usb. But power
only.
2. "Pogo pins" with, neodymium, magnets to snap them to the right place.
Doable but needs testing and probably a few iterations for reliability if
even possible.
3. Dell, Lenovo or HP docking station connectors. Probably widely available
as long as Dell, Lenovo or HP sticks with their format.
4. A 14/15 inch EOMA-68 tablet with a keyboard/battery "dock" connected via
USB cable to the "tablet"

But the current connectors used by the "big" manufacturers are product
specific and quite expensive for low volume production and not sustainable.

Post by c***@sasktel.net
[1] https://en.wikipedia.org/wiki/ThinkPad_X_Series
if you press ctrl f and look for "conver"
[2] https://libreboot.org/docs/hcl/index.html#supported_laptops_
x86intel
[3] http://www.laptopmag.com/reviews/laptops/lenovo-thinkpad-x60-tablet

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by m***@gmail.com
But the current connectors used by the "big" manufacturers are product
specific and quite expensive for low volume production and not sustainable.

and they're also proprietary. i had this happen with the keyboards.
contacting one of the manufacturers of the original parts, they go
"who the f*** are you, and why do you want to demand a copyrighted
part in ridiculously small volume not worth our time, which if our
million-to-billion-dollar client finds out we're letting you have
THEIR copyrighted design they'll never speak to us again, we lose a
fortune.... over _how_ much business did you say you wanted??"

... yah :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large