Hi Luke,
just a tiny note about your mentions of a "tablet/netbook" in https://www.crowdsupply.com/eoma68/micro-desktop/updates/latest-from-shenzhe... .
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
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.
Bonjour,
Le Tue, 13 Dec 2016 17:46:11 +0000 Alexander Ross maillist_arm-netbook@aross.me a écrit:
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.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Amicalement,
Hi Albert,
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.
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
Bonjour,
Le Wed, 14 Dec 2016 20:23:39 +0100 dumblob dumblob@gmail.com a écrit:
Hi Albert,
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.
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?
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).
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.
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.
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?
-- Jan
Amicalement,
Hi Albert,
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?
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,
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.
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
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.
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.
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
Bonjour,
Le Wed, 14 Dec 2016 21:49:13 +0100 dumblob dumblob@gmail.com a écrit:
Hi Albert,
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?
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?
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.
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.
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.
The whole thread is about unwanted interruptions, not user-initiated.
Actually, the whole thread is about disconnectable keyboards.
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.
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.
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.
Kind regards,
-- Jan
Amicalement,
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
2016-12-14 22:46 GMT+01:00 Albert ARIBAUD albert.aribaud@free.fr:
Bonjour,
Le Wed, 14 Dec 2016 21:49:13 +0100 dumblob dumblob@gmail.com a écrit:
Hi Albert,
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?
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?
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.
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.
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.
The whole thread is about unwanted interruptions, not user-initiated.
Actually, the whole thread is about disconnectable keyboards.
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.
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.
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.
Kind regards,
-- Jan
Amicalement,
Albert.
On 12/16/16, dumblob dumblob@gmail.com wrote:
follow http://www.wikihow.com/Change-Keyboard-Layout-in-Ubuntu
switch to the newly added layout of your choice
simulate unwanted interruption (e.g. detach internal or external
physical keyboard and reattach it)
enjoy a different layout than the one you switched to in step 2
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
- 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.
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
On 12/16/16, dumblob dumblob@gmail.com wrote:
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.
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.
On 12/16/16, dumblob dumblob@gmail.com wrote:
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.
On 12/14/16, dumblob dumblob@gmail.com wrote:
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.
On 16.12.14 9:21, Albert ARIBAUD wrote:
Bonjour,
Le ~, 13 Dec 2016 17:46:11 +0000 Alexander Ross maillist_arm-netbook@aross.me a écrit:
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".
been stressed/feel i should after add:
On 13/12/16 17:46, Alexander Ross wrote:
heh im mostly sure luke had no desire for the keyboard to be modular, as keyboards where such a nightmere.
Was in ref the the current laptop and the pains of getting one keyboard to work and problems of long term reliable sourcing of other keyboard models. idk about future laptops.
personally i could see a replaceable keyboard being a cool/pleasant innovation if it can be done with reliability,etc. idk how, lots of thinking needed :).
I don’t expect nor feel the need for every day keyboard swapping. I assume it would be a one off change one makes or to try/use new keyboard layout.
I guess if theres one laptop being shared amongst a bunch of international people then maybe it might be swapped a lot more :/ . Only usage case i can think of.
On 12/13/16, dumblob dumblob@gmail.com wrote:
Hi Luke,
just a tiny note about your mentions of a "tablet/netbook" in https://www.crowdsupply.com/eoma68/micro-desktop/updates/latest-from-shenzhe...
i do wish that crowdsupply could provide on-post comments, but then they'd have to monitor them.
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 :)
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.
Hi Luke,
thanks for flashing a light on that. I'm glad you're staying with USB.
I think this thread is answered.
-- Jan
2016-12-14 20:20 GMT+01:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On 12/13/16, dumblob dumblob@gmail.com wrote:
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.
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 :)
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On 16.12.14 13:20, Luke Kenneth Casson Leighton wrote:
On 12/13/16, dumblob dumblob@gmail.com wrote:
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
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 :)
2016-12-17 16:13 GMT+01:00 chadvellacott@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.
[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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Dec 19, 2016 at 4:24 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
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@lists.phcomp.co.uk
-
Albert ARIBAUD -
Alexander Ross -
chadvellacott＠sasktel.net -
dumblob -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com