arm-netbook November 2017

arm-netbook@lists.phcomp.co.uk

19 participants
18 discussions

Laptop LCD Touch Pad: Display KB Layout Idea
by Alexander Ross 25 Mar '19

25 Mar '19

On the laptops lcd touch pad. Here’s a idea for a feature. When leaning new keyboard layout. Say dovrak for example. The trouble is learning where the new keys are. For me at least, one could do with a constant reminder. What if the lcd touch pad displayed the current pressed keys? Maybe on a image of the keyboard, meaning some way of representing where the key you pressed is relative to other keys. So if its the wrong one you can see where the right one is. This info is only displayed while the keyboard is in use. When the touch pad is in use it switches to a relevant display for touch pad use. As for when the user is using not the touch pad nor the keyboard? What then? display keymap? If playing video display: video controls, time left, is internet speed fast enough for this stream? etc.

5 12

Re: [Arm-netbook] Logos
by John Luke Gibson 22 Sep '18

22 Sep '18

I would highly recommend avoiding any logos, without proper historical reference. One of the problems with traditional Linux icons, are that they are very un-iconic. It's better to be textually based, in my opinion, than to use disorienting imagery. At this point, most of the clay has already set so referencing/alluding-to other gnu projects [such as blender] wouldn't be detrimental, however ascii has a very richer history of use by "hacktivists". Referencing some historically relevant (to "hacktivism") ascii iconography either overtly or subtly, kindof more or less as a hat tip to communities which support said historical events will cause the logo a greater likelihood of being regarded as iconic. I wish I had specific examples, but possibly using cloister black font would be a subtle hat tip to anonymous for some individuals use of various letters in that font as copy-cat of L from Death Note. Another thing of note, would be that we need to be careful who we tip our hats to, to be careful of who in the future people might assume us to endorse. A font is innocuous enough, that it can be adapted later due to circumstance (should a need arise to disassociate) without damaging the recognize-ability of any logo. The universal and modular style of blender, is a good point to mimic. A solid dot in the center of the "O" would probably be a subtle enough correlation to the blender logo. This is the pattern of thinking we need in developing logos and "slogans". Thinking about what sounds catchy only correlates us with random corporate culture. We don't need to be entirely original as we have a history to fall back on. However originality might also help distinguish us from our predecessors, the last thing we want is to fail to distinguish ourselves from your neighborhood corporation. I would recommend Luke to contact Wenqing Yang a.k.a. "Yummei", using the notability of the project to attract their attention. I would like to point out that despite being a cultural figure (famous artist) in the hacktivist community they previously lauched a multi-million dollar successful indiegogo which caused them much heart ache (per their blog) over legal controversy with so-called partners and their personal admonishment that they failed to do enough. >From: Alexander Ross <maillist_arm-netbook(a)aross.me> >To: Linux on small ARM machines <arm-netbook(a)lists.phcomp.co.uk> >Cc: >Date: Wed, 25 Jan 2017 16:07:15 +0000 >Subject: Re: [Arm-netbook] Logos >this all these efforts, got me to have a play around too. :) > > i was started having a go at one idea of letters inserting into each > other kinda like a module. > > I had put E and O in side the M. it then kinda looked like/spelled Meoo > like a cat. > So what about a darn cat logo? maybe a cat playing with a eoma68 card in > its paws? > > sry for the yet another internet cat image type of suggestion, never > thought id be making one heh.

9 18

Re: [Arm-netbook] Logos
by John Luke Gibson 21 Sep '18

21 Sep '18

> The idea about a dot in the "O" of EOMA made me think of fonts where the > dot is in the 0 (zero) to distinguish it from O (capital letter O) As we > all are somehow computer related I would find such a design confusing. If it was really to be in honor of the modularity and progress of blender, one would want to make the "O" not really in any particular font, but to look exactly the shape blender logo, except without the flay or the color scheme: a perfect solid-color circle within another perfect circle. It wouldn't theoretically be confusing because the mark you are thinking of is a hollow circle in an oval. Letter-o'es and zeroes can only sometimes be confusing because in some fonts they are both written as vertical ovals, not just the zero. I'm not sure on the required dimensions of a certification mark, however, the solid-shape flag-esque convention I've noticed among popular one's, often seems to detract from the continuity of the design on the objects that bear them, making them seem particularly foreign and like they don't belong. The vaporwave-esque color palate which most of them choose only add to this affect, as if they themselves are trying to distance themselves on some subconscious level from their endorsements. As a side effect to this, it makes them harder to trust. Any symbolism of any significant body, displays historical awareness.. It's what tells people whether they can trust it, before reading or attempting to judge it. Therein lies the axiom, there is no such thing as an original thought, so, if by means of arbitrary work dedicated to make more concise and thoroughly plastered an announcement of what historical or cultural event may have inspired such thoughts and such work, people will then engage in the arbitrarily difficult work of judging whether the project is sincere or not. In other words, if we don't display more than necessary effort in our symbol that can be recognized with several magnitudes less effort than it took to generate, then no highly-self-valuing person will have any sane reason to take us seriously, because if they took every slightly promising project, which failed to create a Sybil-certificate reputation in this manner, then they would never find a single valuable project in their lifetime (obviously this is an exaggeration).

3 2

HDMI High-Frequency Layout: Recommendations
by Richard Wilbur 17 Jan '18

17 Jan '18

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Thu 3 Aug 2017 Recommendations for this Layout Source (processor) end: Could we shrink the via pitch between constituents of a differential pair (bring the vias of a differential pair closer to each other) and combine the anti-pads into an oval shape on each layer? This reduces fringing fields and thus parasitic capacitance. I like the ground vias close to the signal vias between differential pairs. It would be lovely to get a ground via close to the via on HTX2P and possibly move the one between HTX2N and HTX1P closer to the signal vias (if the signal vias of pairs can be moved closer with combining the anti-pads). What is the intra-pair skew from the processor lands to the first signal vias? I wonder if we could move the vias on the short lines a little further from the processor and make up some of the skew in that segment before we leave it? Sink (connector) end: Same thing for differential pair vias--HTX0 and HTX2--it would be lovely to shrink the via pitch and combine anti-pads (if possible). Again, I like the ground vias close to the signal vias HTX2P, HTX2N, and HTX0P. It would be lovely to be able to either put a new ground via closer to the signal via on HTX0N or move the one on the ground shield trace closer. I like what you were showing on the video with the signal vias at the connector lands: putting a neck on the trace between the via and the land should dampen the spirits of the solder but not the signals. If we could reduce the signal via pitch by combining anti-pads at the connector, we might be able to move the HTX1P and HTXCN signal vias to the other side of the lands next to the other side of the differential pair, thus equalizing the skew on the segment between the ESD chip pads and the connector pads. If that worked the final touch might be to add a ground via between DC3 pin 10 (GND) and the board edge for return current paths. Other than that, I would try and move as much of the skew compensation close to the source of the skew as possible. I'm not sure what I'm looking at as you mentioned the ground reference planes were solid under the HDMI differential pairs, but it looks like they have voids under the signals in the pictures. Am I seeing a negative, that there are only little strips of conductor in the ground reference plane directly under the high-frequency lines? Neither of these interpretations is very satisfactory, nor do they seem to represent reality. Please let me know what can and can't be done and I will adjust recommendations accordingly.

4 143

Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model
by John Luke Gibson 23 Dec '17

23 Dec '17

Neverminding the ridiculous length of that subject line.. I just thought an interesting thought. First, a little context, (I know how rms feels about blockchains) I was investigating slock.it and thinking to myself "why don't they just make a hardware standard like eoma instead of closing their development and calling it open?" (Like, Pi-Top is [n]ever gonna release those stl files) (I realize that's a loaded 'just' cause it sounds easy, but is one of the most difficult possible) Then, it dawned on me: Lulzbot doesn't do that.. Wait, Lulzbot exclusively uses open software in their development.. Then *bam* like a boulder (nothing to do with Lulzbot): GPL-violations, improper GUI training, failing to extend using APIs/Addons, failing to bugsmash/'track-issues', failing to participate in mailing-lists and irc, failing to simply fork when development goals conflict, planned esoteric-ism and/or planned obsolescence, failure to secure clientèle data by using fully free systems (when relevant), failure to participate-in and be-aware-of public conversations about the underlining security of said systems (when relevant), failure to disclose supplychain information/identities (when relevant), failure at general transparency. All of these things traditionally go wrong with not only companies that use open source, but companies in-general. Then, it truly truly dawned on me, free software needs standards organizations as well.

13 50

FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski 18 Dec '17

18 Dec '17

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

2 5

Mali / Lima
by mike.valk＠gmail.com 11 Dec '17

11 Dec '17

It seems that someone has picked up the tainted project. https://github.com/yuq?tab=repositories

7 7

Re: [Arm-netbook] New Risc-V fully free chip
by ronwirring＠Safe-mail.net 01 Dec '17

01 Dec '17

-------- Original Message -------- From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Eco-Conscious Computing <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] New Risc-V fully free chip Date: Sun, 19 Nov 2017 03:44:19 +0000 >suggestions on how > to contact them appreciated. Current Team Members: Rahul Bodduna (rahul.bodduna(a)gmail.com) Neel Gala (neelgala(a)gmail.com) Arjun Menon (c.arjunmenon(a)gmail.com) G Vinod (g.vinod1993(a)gmail.com) Abhinaya Agrawal (agrawal.abhinaya(a)gmail.com) G S Madhusudan (gs.madhusudan(a)cse.iitm.ac.in, madhu(a)macaque.in) V. Kamakoti (kama(a)cse.iitm.ac.in, veezhi(a)gmail.com) For Queries/Collaboration/Feedback : shakti.iitm(a)gmail.com __________________________________________ > arm-netbook mailing list arm-netbook(a)lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook(a)files.phcomp.co.uk

4 14

Top Priority Software Tasks
by Adam Van Ymeren 30 Nov '17

30 Nov '17

Hey Luke, As I eagerly await the preproduction board, I figure it would be a good idea to touch base on what needs doing on the software side. I've started looking at http://rhombus-tech.net/allwinner_a10/source_code/ for inspiration. But I'd like to know which tasks are a priority for you to deliver the current crowd supply pledges. Cheers! Hope the Shenzen was fun. -Adam

8 16

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations Vias Moveable?
by Richard Wilbur 26 Nov '17

26 Nov '17

Working on the high-frequency taper, a couple things have been bothering me--the two ground vias circled in the attached picture. Are they either optional or moveable? If so, even moving them East or Northeast takes some pressure off the taper. If not, we'll work around them but it is a little more complicated. Richard

3 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook November 2017