[Arm-netbook] MIPI DSI instead of RGB/TTL - the only way out of the blind alley

[dumblob]

Hi Luke,

sorry for the few months delay - I was stuck with moving, family, job
applications, etc.

I would like to bring up again the painful topic of a long-sustainable
graphical interface in the EOMA68 specification (
http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/ ) as the
RGB/TTL solution is so utterly bad choice.

RGB/TTL is way too slow and highly limited (alone, but even more in EOMA
specifications):

a) maximum resolution 1366x768 (even though the current EOMA should be
capable of 1440x900)
b) maximum pixel clock about 148.5 MHz (~ max 71.6 fps at the mainstream
1920x1080 with visual artifacts and high EMI disqualifying EOMA for mobile
devices with radios)
c) maximum color depth 18 bits (3x6)
d) eats a lot of pins (18) already in this lowest quality set up
e) requires HW changes (i.e. disallows sustainable plug & play) in case
EOMA should mitigate the limitations above (parallel interfaces require
addition of many pins) - this is anyway impossible, because all pins are
already in use
f) easy (not requiring a chip) conversion to VGA output; conversion chips
to all (!) other interfaces (which are modern, serial, and ubiquitous) is
needed (and is more expensive than a serial->RGB/TTL because of very low
purchaser interest)
g) easy implementation in FPGA (few hundreds of LUTs)

Yet EOMA does not even allow adding any better display interface, because
there are not enough "free" pins for any modern serial interface (MIPI DSI,
eDP, HDMI, ...). This effectively totally (!) disallows manufacturers of
EOMA cards to add an SoC <-> MIPI/eDP/HDMI circuity on an EOMA card to
provide at least mainstream (!) resolution output with 24 bit colors for
internal displays (not talking about 2017, when it will supposedly be 4K at
30 fps with 24 bit colors).

In other words, this only one fact degrades the whole EOMA to the category
of yet another toy (as every other libre general-purpose user computer HW
failed up until now). By the way I had to publicly confess this during my
talk at the conference OpenAlt 2016 (https://openalt.cz/2016 , there is a
full recording).

After reading through all the important emails from Arm-netbook beginning
in 2010 (yeah, 571509 lines of text), many of your posts on different web
servers, and watching nearly all your videos, I did some research on
display interfaces. Few quick facts based on my findings follow (yes, I
focus on lower mainstream and mainstream "fat" embedded and mobile segment,
not on total low-end, because there we have zillion of existing PCBs all
offering basically the same HW interfaces - some of them even libre).

From panelook.com (size >= 7.0", px density >= 160 PPI):

* LVDS: 382 panels in MP YEAR 2016 (2015: 53) => ratio (the higher the
better) 53/382 = 0.138
* MIPI DSI: 239 panels in MP YEAR 2016 (2015: 50) => ratio 50/239 = 0.209
* eDP: 233 panels in MP YEAR 2016 (2015: 66) => ratio 66/233 = 0.283
* RGB/TTL: 15 panels in MP YEAR 2016 (2015: 2) ratio 2/15 = 0.133

(the ratio shows how much is the certain interface on rise)

Video interfaces from data sheets of few tens of more performant (i.e.
having more computing power) mobile SoCs (no AMDs, no Intels) in 2015 &
2016:

* LVDS: nearly nowhere
* MIPI DSI: everywhere (!)
* eDP: nearly nowhere (in contrast to big chips like Intel i5/i6/i7, where
eDP is largely prevalent)
* RGB/TTL: nearly everywhere (but especially on smaller SoCs)

We can see a strong trend of LVDS disappearing (though having still the
major position in 2015 & 2016), MIPI DSI and eDP on fast rise and RGB/TTL
on a total decline reaching it's physical limits. Add the fact, that MIPI
DSI is present on basically every mobile SoC since cca 2014 (in contrast to
2012 when EOMA was looking for "the ultimate video interface" and when
RGB/TTL was really the only portable option) and moreover is easily and
cheaply convertible to eDP or to LVDS, we have a clear winner. By the way,
even Intel also recommends an external MIPI DSI to LVDS and MIPI DSI to eDP
bridges for his SoCs. Based on all that I'm confident, that in the upcoming
10 years, the SoC market will use MIPI DSI everywhere as the main standard
and eDP for the few biggest chips.

MIPI DSI also doesn't have the issues as LVDS, when the specification did
not cover the chosen width and properties of implementation and thus
prevented bundling universal conversion chips.

MIPI DSI offers:

a) highest state-of-the-art resolutions (not limited to, but supporting
4096x2160)
b) highest state-of-the-art refresh rates (not limited to, but supporting
120 fps at 1920x1200; i.e. pixel clock about 276.4 MHz) without visual
artifacts and while remaining low-power
c) 24 bit color depth (3x8)
d) eats just 4 pins for minimal configuration with one lane (in practise 4
lanes are most common, so 10 pins will be needed)
e) requires none (increasing frequency) or very minimal (adding two pins as
a new data lane) HW changes (MIPI DSI is a serial interface)
f) VGA output (hell it should die out already!) requires a conversion chip
(which is not so expensive, so it shouldn't influence the Micro Desktop PC
PCB nor notebook PCB price; actually I would not provide VGA at all on
these consumer devices, but rather (e)DP or HDMI, because consumers do not
want VGA any more and external eDP -> VGA converters are about 5$ with free
shipping world-wide for those who need it or want to be really eco-friendly
and use the few surviving VGA devices at the expense of higher electrical
consumption)
g) easy implementation in FPGA (there are fully functional existing
implementations having just about 2000 LUTs)

But how to cope with this when there is already an EOMA card in
manufacturing?

Let me boldly demonstrate "thinking outside the box" (kicked off by email
from Luke from Sat, 13 Jul 2013 17:22:41 +0100 and supported by the "take
advantage of the MIPI / eDP" statement of Luke from Thu, 10 Apr 2014
10:48:46 +0100).

Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
having a HW way to choose from these?

Yes we can! EOMA already counts on several types of PC Cards (originally
called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker
(Type II - 5 mm). Let's declare the thicker cards to be high-end and offer
only MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!

The "high-end" specification shall then also be extended allowing higher
thermal dissipation (5W is too low - maybe 15W would be OK as it's still
easy to cool passively) etc. to accommodate "high-end" (actually
mainstream, but in this context it's high-end) requirements.

Speaking about thermal dissipation, I'm not sure that in case of the
high-end card type, this limit should be a fixed one. I would probably
prefer the 15W value as a strong recommendation instead of a firm
requirement. While always (disregarding whether it's smaller than 15W or
not) requiring to readably and fully visibly to the end user quote (at best
on the outermost coating) the maximum dissipation of the whole particular
card under heavy load. Why? Because there will be a manufacturer offering a
special super hyper mega powerful card implementing a "turbo" mechanical
switch automatically overclocking the by default heavily underclocked
8-core beast.

This could then be finally called useful and sustainable for 10 years.

Recap of solved issues:

* No more copyleft-like/religious constraints ("we require you to only use
libre and eco-friendly stuff, not the new fast non-libre SoCs with
non-refurbished eco-unfriendly displays"), but rather a permissive approach.
* No more issues with non-tiny display panels.
* No issues with users putting a wrong card to the slot.
* No more issues with dissipation.
* No more issues with libre world being old, slow, ugly looking, etc. (as
I'm often told, because it unfortunately currently holds).
* No more issues with decision makers, who will finally get the freedom of
choice from several cards (keep in mind what the marketing/portfolio
research says - a set of more similar but still diversified
products/services sell significantly better than one product/service
disregarding whether it's high-quality or not).
* Useful for the upcoming hybrid phone (
http://rhombus-tech.net/community_ideas/hybrid_phone/ ) - lower number of
pins, lower consumption.

Enjoy the new life in China with your family and good luck with discovery
how the world's real HW production and market works,

-- Jan

[Luke Kenneth Casson Leighton]

Post by dumblob
Hi Luke,
sorry for the few months delay - I was stuck with moving, family, job
applications, etc.
I would like to bring up again the painful topic of a long-sustainable
graphical interface in the EOMA68 specification (
http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/ ) as the
RGB/TTL solution is so utterly bad choice.

nope. been over this many many times.

Post by dumblob
RGB/TTL is way too slow

no it's not. most mid-end SoCs can do up to 2048x2048 @ 30fps, and
can certainly do 1920x1080p60 over RGB/TTL.

it's nonsense to say that it's too slow.

Post by dumblob
and highly limited (alone, but even more in EOMA

no it's not. the 3.3mm card height is reserved for 1920x1080p60.

Post by dumblob
c) maximum color depth 18 bits (3x6)

that's because if you look at most mid-end LCDs they only do 18 bpp
anyway. it also means that the extra 6 pins which were saved could be
dedicated to SPI and two more EINTs, which turned out to be crucial.

most people's eyes are incapable of telling the difference. really.

Post by dumblob
f) easy (not requiring a chip) conversion to VGA output; conversion chips
to all (!) other interfaces (which are modern, serial, and ubiquitous) is
needed (and is more expensive than a serial->RGB/TTL because of very low
purchaser interest)

yep. very easy. or, for the low-cost products, it's not even needed
at all: 320x240, 480x320, 640x480, 800x480 and 800x600 LCDs are all
RGB/TTL.

go look it up on panelook.com.

Post by dumblob
g) easy implementation in FPGA (few hundreds of LUTs)
Yet EOMA does not even allow adding any better display interface, because
there are not enough "free" pins for any modern serial interface (MIPI DSI,
eDP, HDMI, ...). This effectively totally (!) disallows manufacturers of
EOMA cards to add an SoC <-> MIPI/eDP/HDMI circuity on an EOMA card

nonsense. they can always add a MIPI-to-RGB converter or an
eDP-to-RGB converter IC on-board the Card.

Post by dumblob
to
provide at least mainstream (!) resolution output with 24 bit colors for
internal displays (not talking about 2017, when it will supposedly be 4K at
30 fps with 24 bit colors).

the processors you're referring to are so power-hungry that they
require special cooling and/or fans. in other words, they're *well*
beyond the thermal design capability of EOMA68 anyway.

also, the attention to design when dealing with 4k displays is
EXTREME. not even rockchip's own EVB for the RK3288 is capable of
driving a 4k HDMI display... because there's too much noise, degrading
the signal.

the data rates you're talking about here are ... well, let's work it
out. it's 1920*2*1080*2*60*8 = 3981312000. that's close to FOUR
gigahertz.

to create boards where the data rates are that high requires extreme
special care and attention to layout. it's radio frequencies,
basically.

now, here's the thing: at this early stage of the project, i can cope
with designing boards that are up to a maximum frequency of... 100mhz
for RGB/TTL, and even 1ghz for HDMI 1.4 (1920x1080x60*8), by following
some strict design rules that have taken me a long while to learn...

... but 3.7 ghz? fuck no. you must be joking. with the upcoming
RK3288 prototype of course i'm going to try it out, but if it actually
works i'm literally going to end up laughing on the floor, manically
and hysterically at the complete fluke.

bear in mind that for a standard to be successful its interface
capability must be MANDATORY, if you start FORCING the standard to
support 3.7 ghz data transfer rates, you just raised the bar - the
cost of development to a whooole new level.

EOMA68 is designed to be *affordably* implementable (by even someone
like me who is self-taught).

Post by dumblob
In other words, this only one fact degrades the whole EOMA

repeat after me: there is NO SUCH THING as an EOMA standard. there
is only a FAMILY of EOMA standards, of which EOMA68 was chosen as the
first "easily and affordably implementable" one.

Post by dumblob
to the category
of yet another toy (as every other libre general-purpose user computer HW
failed up until now). By the way I had to publicly confess this during my
talk at the conference OpenAlt 2016 (https://openalt.cz/2016 , there is a
full recording).
After reading through all the important emails from Arm-netbook beginning
in 2010 (yeah, 571509 lines of text),

ye gods man!

Post by dumblob
many of your posts on different web
servers, and watching nearly all your videos, I did some research on
display interfaces. Few quick facts based on my findings follow (yes, I
focus on lower mainstream and mainstream "fat" embedded and mobile segment,
not on total low-end, because there we have zillion of existing PCBs all
offering basically the same HW interfaces - some of them even libre).

yeahyeah. the 72mhz ECs. none of them are capable of driving LCDs -
the framebuffer alone overwhelms their capacity both for internal
memory, internal bus rate and external data transfer rate.

many of the low-cost ECs actually use SPI-based or MCU-based (8080)
LCDs (with something like an HX8357D controller IC) because these have
their own internal framebuffer RAM (on-board)... quite cool,
basically. it's like a tiny embedded version of the x86 IBM PC with
its AT Bus....

...but i digress.

Post by dumblob
* LVDS: 382 panels in MP YEAR 2016 (2015: 53) => ratio (the higher the
better) 53/382 = 0.138
* MIPI DSI: 239 panels in MP YEAR 2016 (2015: 50) => ratio 50/239 = 0.209
* eDP: 233 panels in MP YEAR 2016 (2015: 66) => ratio 66/233 = 0.283
* RGB/TTL: 15 panels in MP YEAR 2016 (2015: 2) ratio 2/15 = 0.133

great: you _did_ look it up! errr... except you didn't divide them
up by resolution. that throws your enquiries off completely.
basically, RGB/TTL is only common for 320x240 up to 800x600 (which is
the low-cost end). above 800x600 the parallel data bus skew is too
much... which is why these differential-pair serial buses were created
in the first place.

Post by dumblob
(the ratio shows how much is the certain interface on rise)
Video interfaces from data sheets of few tens of more performant (i.e.
having more computing power) mobile SoCs (no AMDs, no Intels) in 2015 &
* LVDS: nearly nowhere
* MIPI DSI: everywhere (!)
* eDP: nearly nowhere (in contrast to big chips like Intel i5/i6/i7, where
eDP is largely prevalent)
* RGB/TTL: nearly everywhere (but especially on smaller SoCs)

yes. so, as predicted, the decision to go with RGB/TTL makes
sense... and still stands.

lower-cost SoC manufacturers don't like spending the money on royalty
licenses for MIPI or eDP, plus it makes absolutely no sense to use
MIPI or eDP for 320x240, 480x320 or 640x480 LCDs.

plus, the cost of a converter IC is a far greater ratio of the BOM at
the lower-cost end than it is at the higher-end... and RGB/TTL is the
de-facto interface of choice at the lower end.

... you _did_ read the "interface selection" section in the white paper, right?

Post by dumblob
bridges for his SoCs. Based on all that I'm confident, that in the upcoming
10 years, the SoC market will use MIPI DSI everywhere as the main standard
and eDP for the few biggest chips.

... which we'll get to.... *with another standard*... with the 3.3mm
card height variant being an interim stand-in to cover the intervening
time... where profits from sales of designs based around the *CURRENT*
standard will help fund the next one.

... you didn't think i was going to stop at just the one standard, did you?

Post by dumblob
Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
having a HW way to choose from these?

NO.

Post by dumblob
Yes we can!

NO. absolutely not.

Post by dumblob
EOMA already counts on several types of PC Cards (originally
called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker
(Type II - 5 mm). Let's declare the thicker cards to be high-end and offer
only MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!

massive problem *created* which DESTROYS the standard even before
it's implemented.

allow me to go through it.

(updated: i spotted another problem, which is that it would be
impossible to prevent the 3.3mm "low end" cards from being inserted
into 5.0mm "high end" slots... potentially electrically damaging both
Card and Housing. on this point alone what you're suggesting is a
non-starter. even if you tried to make them interoperable it would
have to be 3.3mm which was the "high" end and 5.0mm the low end,
because 5.0mm low-end Cards would NOT PHYSICALLY FIT into a 3.3mm
slot.. so now we proceed to explain why *that* idea does not work,
either... ).

af first glance, it seems like a great idea: add two different video
interfaces on the same pins. so.

which pins do you use for which functionality?

* pin 1: RGB Red 0 *AND* MIPI lane 0 tx-
* pin 1: RGB Red 1 *AND* MIPI lane 0 tx+

....
....

now let's design the housing boards around that. let's make one which
has RGB/TTL, and the other which has MIPI.

so, we've got hard-wired pins for RGB on say a 7in tablet

and we've got hard-wired pins for MIPI on say a 14in laptop.

great!

ok, so now let's select some SoCs.

right. first SoC we pick... we find that it has dedicated pins for
MIPI, and dedicated pins for RGB/TTL. so we are forced to find an
ultra-high-speed multiplexer SoC. problem "solved".

second SoC we pick... we find that it has shared pins (multiplexed)
for MIPI and RGB/TTL. they DO NOT MATCH OUR ARBITRARILY CHOSEN
ARRANGEMENT. now we try to use the same high-speed multiplexer SoC...
only to find that it requires SEPARATE inputs... and... err... now we
have to wire the same pins from the SoC to two sets of pins on the
multiplexer IC... now we have signal-bounce to deal with (dual
path)... and double-impedance-matching.... and it's getting alarmingly
complex.

third SoC we pick... we find that it has shared pins which are
COMPLETELY DIFFERENT FROM THE SECOND SoC.

fourth SoC we pick... has MIPI but does not even have RGB/TTL.

fifth SoC we pick... has RGB/TTL but does not have MIPI.

in ALL of these instances, it's simply flat-out impossible to do the
board layout... why? because there's simply not enough room to fit
the converter IC onto the board. have you _seen_ how tiny the EOMA68
PCBs are? 78.1 x 47.3mm with a height limit of 1.9mm on TOP and 1.6mm
on BOTTOM, that's with a 1.2mm PCB. i don't even want to know how
much 0.8mm PCBs cost.

can you see how this quickly gets into absolute hell on earth, with
costs rapidly escalating?

what converter IC do you pick? does one even exist? is it common
enough so that it has alternative competition so that we don't end up
with the entire standard being critically dependent on ONE company's
IC and them going out of business?

can you also see how it would create total confusion for end-users,
thus DESTROYING all and any possibility of being a successful and
simple mass-volume standard?

can you imagine the conversations of the sales people, "oh i'm sorry,
you bought that 7in tablet which only does RGB/TTL? i'm sorry, you
can't use the more modern MIPI Computer Card, you have to THROW AWAY
that 7in tablet housing".

it's total nonsense... and in direct violation of the purpose of the
standard: to reduce e-waste.

so... NO. not going to happen.

what *is* going to have to happen however is a new standard's created
[and it will either use MIPI or it will use eDP... or it will have
both on separate pins]. this would be much more suitable for the
incoming mid-end SoCs (intel and amd are going to have to take a back
seat until they sort out their backdoor co-processors and proprietary
hardware drivers].

but, it is necessary first to find a suitable connector. funnily
enough there's a guy who has located games cartridge connectors... i
forget which one... NES? Game Boy? which has 100 pins....

http://old.pinouts.ru/Game/CartridgeGameBoy_pinout.shtml

nope, not that one, it's only 32...

https://wiki.nesdev.com/w/index.php/Cartridge_connector#Pinout_of_72-pin_NES_consoles_and_cartridges

NES - 72, ah HA! err... except they're enormous:

https://en.wikipedia.org/wiki/Nintendo_Entertainment_System_Game_Pak#60-pin_vs._72-pin_cartridges

13.3 x 12 x 2cm or something mad.

so, back to the drawing board on that one.


basically it's not as simple as it sounds. just add an extra
interface, right? no problem, right? wrong. there's *really* good
reasons why the functions on EOMA68 only have GPIO multiplexing, and
it's because GPIO is the lowest common denominator function that can
reasonably be expected of any arbitrarily-chosen pin.

we can't even multiplex say SPI and UART onto the same pins, because
there's absolutely no guarantee that any arbitrarily-chosen SoC *has*
SPI and UART multiplexed onto *EXACTLY* the same arbitrarily-chosen
pins [for a standard]. that leaves the burden on *software* to do
bit-banging of either UARt or SPI... and god help you if the SoC
doesn't support EINT capability on the chosen pins (because the others
had to be used for other purposes), and you have to do high-frequency
CPU-intensive polling.

and the moment you start saying "ohh it's okay to have one function
but not the other on any given card" you've just fucked the entire
standard in the "salesman" scenario above. nobody would EVER trust
the standard to be "eco-conscious" if you told them that they were
forced to throw out perfectly good Housings.

i appreciate your thoughts, but there's far more to take into
consideration here than whether a particular interface is
"up-to-date". at least six completely different inter-related
criteria had to be satisfied, with *none* of them being "open for
negotiation".

Post by dumblob
Speaking about thermal dissipation, I'm not sure that in case of the
high-end card type, this limit should be a fixed one.

again it comes down to what the boards (chassis manufacturers) can
cope with. remember, whatever is picked *has* to be covered by *ALL*
chassis manufacturers.

so if you picked up to 15W, *ALL* chassis manufacturers *MUST*
provide up to a maximum of 15W...

... or it is necessary to put in the EOMA68 I2C EEPROM, "this chassis
can provide up to N watts power if needed, and has the thermal
dissipation capability to deal with it".

it gets complicated, quite quickly, but would be doable.

hmmm, and the nice thing is, it's an upwards-compatible expansion of
the EOMA68 standard which doesn't interfere with the existing release.

i like it.

l.

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

[Luke Kenneth Casson Leighton]

Post by dumblob
Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
having a HW way to choose from these?
Yes we can! EOMA already counts on several types of PC Cards (originally
called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker
(Type
II - 5 mm). Let's declare the thicker cards to be high-end and offer only
MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!

To be specific, EOMA68 includes Type I, Type II and Type III already. There
are differences in permitted power, and RGB resolution. These differences
run in opposite directions, in order to make sure that any combination that
fits will work.
WRT resolution, Type I is the high-end, with card-minimum/housing-maximum
1920x1080, because a Type I housing will accept _only_ Type I cards. Thus
anything with a 1920x1080 screen has a Type I slot, and any card that
physically fits will drive that display.

nooo, 5.0mm is the 1366x768 because the 5.0mm needs to be prevented
and prohibited from being physically inserted into incompatible 3.3mm
(1920x1080) slots.

(AIUI, a Type II housing can have a 1920x1080 display, as long as that
display will accept and upscale a 1366x768 signal.

NO. absolutely not. that is a completely unacceptable technical
burden on the manufacturers of the housings, forcing them to have
additional circuitry which may or may not be used.... and may or may
not be actually available on the open market.... and may actually end
up being far more costly than the processor utilised in the Card.

any kind of resolution scaling at these framerates and buffer sizes
it actually needs a full processor - with several hundred megabytes of
DDR2 / DDR3 RAM - to perform the conversion.

so no - absolutely not. you connect the LCD to the EOMA68 bus on the
Housing, the LCD's resolution is fixed as decided by the manufacturer
of the Housing, and that's the end of it.

Then either a Type I card
or a Type II card exceeding the minimum specs can output full 1920x1080, but
it will work with even the minimum Type II card's 1366x768.)
The point is, any card _must_ work in any housing it physically fits in. So
if you want Type I to support MIPI, that's great -- but that Type I still
fits in a Type II, so it must also be able to output RGB/TTL on the same
pins,

... correct.... but worse than that it must be on the *exact*
dual-function pins as arbitrarily specified in the propsed [completely
not-thought-through] standard.

and there must be a mechanism to autonegotiate this depending on the
housing.

correct.

I don't think adding autonegotiation here is particularly hard (basically
just defining a flag in the I2C EEPROM),

correct.

but the need to support both
interfaces negates some of the benefits of MIPI,

not really relevant

and adds complexity to all
cards supporting MIPI,

"insane, hard to implement and with ICs that probably don't actually
exist" complexity

and I'm not sure that complexity (multiplexer, and in
some cases, MIPI->RGB conversion IC) can actually fit on a crowded EOMA68
card.

correct.

Post by dumblob
The "high-end" specification shall then also be extended allowing higher
thermal dissipation (5W is too low - maybe 15W would be OK as it's still
easy to cool passively) etc. to accommodate "high-end" (actually
mainstream,
but in this context it's high-end) requirements.

Type I and Type II are currently limited to 5W, while Type III is limited to
10W. Again, these have to be in this order, because any card must work in
any housing it physically fits. So a 5W card can be powered by a 10W power
supply, but not the other way around.
I think 10W is a hardware limit of the connector (4 pins at 0.5A per pin);

correct. ah, i'd forgotten about that. yeah you do not want to be
overheating the pins. so, 10W limit it is.

Post by dumblob
Speaking about thermal dissipation, I'm not sure that in case of the
high-end card type, this limit should be a fixed one.

Obviously, technically skilled people will overclock and overwatt specific
EOMA68 cards in housings that they know can supply more power.

outside of the standard.... probably.

But the
minute you change this behavior from "hackers breaking the rules" to
"there are no rules", you've made it so that the whole promise of EOMA
("Just plug it in; it will work") can no longer be kept.

correct. and that's why these things have to be thought through very,
very carefully, and simplly not permitted - outright banned - if there
is even the slightest possibility of confusion or harm.

remember the goal is 100 million units and above per year. even the
SLIGHTEST chance of confusion could result in millions of units
returned, resulting in a catastrophic loss of confidence in the
standard.

there is NO WAY the standard can be "sacrificed" just for the benefit
of some arbitrary
"nice-to-have" decision or short-term profit.

I personally would be fine with that -- in fact, I would be fine with a lot
of things that are defined in the EOMA68 standard being just a matter of
labeling, and leave it on the user to choose compatible parts.

as long as the compatibility is "everything, always works [even if
it's a bit slower]" i don't care.

the MOMENT that becomes "it MIGHT work, but it might not" then the
standard's fucked and six years (and counting) have been utterly
wasted, irrevocably destroyed in an instant.

But Luke's not designing this standard for me; he's designing it for people
who would get confused and buy a 25W card and a 10W-max tablet housing, and
not understand why they don't work.

absolutely correct.

If you're targeting those people (which
you have to, to get volume), you have to make it work for them.

absolutely correct.

this isn't a "techie standard wanna plug in yer favurit memry upgrad
just undo da scruz n read duh instrucshunns on da in'ur'ne' "

just as that pc journalist said a couple months back (about gaming
pcs being too hard), it's for people with big fat fingers who are
afraid to drop the screwdriver and damage things.

one button.

press it.

card comes out.

put new one in.

it will work.

that simple.

and it stays that simple.

this is not negotiable.

l.

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

[Luke Kenneth Casson Leighton]

On Tue, Dec 13, 2016 at 8:55 PM, Luke Kenneth Casson Leighton

Post by Luke Kenneth Casson Leighton
nooo, 5.0mm is the 1366x768 because the 5.0mm needs to be prevented
and prohibited from being physically inserted into incompatible 3.3mm
(1920x1080) slots.

I think we're failing to communicate here. Type I is 3.3mm, Type II is
5.0mm. As far as I can tell, we're saying the same thing so far.

wheels turn a bit slowly in my head at the moment... :) *click* yes
you're right.

I'm _not_ saying to require it, I'm saying I thought a housing _can_ have
it. There's no "forcing" them to, and I get that it makes no economic sense
in almost all cases. But _if_ a particular manufacturer wants to make a
particular housing with a high-resolution display, built-in upscaler, and
Type II (5.0mm) slot, that's not a problem, is it?

ah.... ah.... oo! as long as the housing was absolutely guaranteed
to work at 1366x768 *and* 1920x1080... you're absolutely right, it
would be fine!

Post by Luke Kenneth Casson Leighton
any kind of resolution scaling at these framerates and buffer sizes
it actually needs a full processor - with several hundred megabytes of
DDR2 / DDR3 RAM - to perform the conversion.

Or ASICs, such as are in most ordinary LCD monitors and TVs.

these days most of them are actually custom full processors (you
remember that vulnerability report recently about LCDs being hackable
over their HDMI interfacee?) the framebuffer is so large -
1920x1080x8x4 = 64mb (!!)

The specific application I was thinking of is "Smart TV": a 1080p TV (or
projector) with an EOMA68 slot in the side of it. It should already be able
to handle 1080p, 720p, and other resolutions from the DVI/VGA/etc. inputs,
so for little additional cost, it could handle both 1366x768 and 1920x1080,
from either Type II or Type I cards respectively.

... remember there's two cases (at the moment) where up to 1920x1080
is supported by 3.3mm cards and housings, and up to 1366x768 is
supported by 5mm cards and housings. what you're proposing below is
incomplete but i get the general idea

A Support _only_ 1920x1080 from EOMA68, and have a Type I 3.3mm slot; anyone
with a spare Type II card can't run a lower resolution, but has to buy a
new card.

baaad.

B Support _only_ 1366x768 from EOMA68, and have a Type II 5.0mm slot; anyone
with a spare Type I card can use it, but has to live with the lower
resolution and upscaling artifacts, even though their card can do better.

blegh.

C Support 1366x768 and 1920x1080, and have a Type II 5.0mm slot; anyone with
a spare Type II card can use it with upscaling, while anyone with a Type I
card can use it at full resolution.

better.

Are you saying the _only_ ways for such a "Smart TV" to be EOMA68 compliant
are options A and B, and there's no way to do option C?

no, you've come up with a really good suggestion (thanks to the OP
for the question and the discussion opportunity).

it's a hell of an extra technical cost - to have a full custom
ASIC/processor and some DDR2/3 RAM to do the upscaling.... but if
that's what it takes - and it's not unreasonable - then that's what it
takes.

ha.

okay.

so we have, in the resolution department:

* type II 5.0 mm cards may expect up to 1366x768 as guaranteed and
given "native" resolution(s)

* type I 3mm mm cards may expect up to 1920x1080 as guaranteed and
given "native" resolution(s)

* type II 5.0mm cards may expect housings to provide "upscaling"
support for resolutions beyond 1366x768, a notification of the full
list of available resolutions in the I2C EEPROM (in the form of DDC
data) and, hmmm.... we'll need some form of auto-detection or
standards-compliant means and method of communicating the desired
resolution. hmmm....

and in the power-provision department:

* all housings MUST supply up to 5.0 watts

* all housings MAY indicate in the I2C EEPROM that they have the
capability to extract sufficient heat away from the card in order to
support up to 10.0 watts. that'll probably involve a fan in the
housing, pointing directly at the Card casework.

oo this is actually quite exciting.

l.

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

[Luke Kenneth Casson Leighton]

Glad we're on the same page.

:)

On Wed, Dec 14, 2016 at 5:36 AM, Luke Kenneth Casson Leighton

Post by Luke Kenneth Casson Leighton
* type II 5.0mm cards may expect housings to provide "upscaling"
support for resolutions beyond 1366x768, a notification of the full
list of available resolutions in the I2C EEPROM (in the form of DDC
data) and, hmmm.... we'll need some form of auto-detection or
standards-compliant means and method of communicating the desired
resolution. hmmm....

I finally found the documentation for display-timings in devicetree.
As I suspected, it already supports an arbitrary number of modes, and
specifying one of them as native/preferred.

ah. rrright. okay. two things:

(1) the way it's going to have to work is: you read the EOMA68 I2C
EEPROM @ addr 0x51, get the housing "id", and from there *decide which
dtb fragments to load*. there's a patch related to beagleboards and
so on which is being worked on that allows numbered pointer-references
in devicetree to be replaced with arbitrary pre-compiled binary dtb
fragments.

(2) getting the various settings isn't the problem (load DDC data
over I2C like you would from any VESA-compliant monitor), picking the
preferred one according to the devicetree specification isn't the
problem, it's *TELLING* the hardware which one *HAS* been picked
that's the problem.

now, if this was HDMI, it would not be a problem. HDMI:
auto-detection is part of tthe protocol. VGA? not a problem (at
least with modern monitors) - auto-detection can be designed in. but
RGB/TTL? naah. there's absolutely no meta-data.

even in instances where LCDs contain DDC data, it's often completely
and utterly wrong, so you have to use it as a "guide", experiment,
then completely ignore it and hard-code the values that *WORKED* into
the linux kernel source / dts.

now you have two possible (or potentially even more) resolutions to
pick from... how the hell do you tell the IC (whatever it is) which
one to use?

no idea - so that needs to be resolved, first, before the EOMA68
standard is to be augmented.

i'm not going to put something into the standard which hasn't at
least been thoroughly researched.

l.

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

[Luke Kenneth Casson Leighton]

http://www.chrontel.com/index.php/products/display-interface/ch7018-lvds-transmitter-up-scaler-tv-encoder#

need to find the datasheet for that.

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

[Luke Kenneth Casson Leighton]

http://www.silicondevice.com/file.upload/images/Gid1300Pdf_CH7018A%20Datasheet%20Rev2.2.pdf

oh look - the CH7018A datasheet.

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

[Luke Kenneth Casson Leighton]

blegh. only does up to 1024x768 input resolution. however what i was
referring to is in section 4.0 (p32) of the datasheet, you use the
serial port to tell it what modes its input is set to, as well as what
the output mode is.

so, you get the general idea - it's just a pity that chrontel don't
have any more modern products but they'll be quite likely to be other
manufacturers... i just want to make absolutely absolutely sure that
some ICs actually exist that aren't EOL.

anyone got time to go over TI's web site and others? it's too
frickin awkward to do this kind of research from china... unless it's
a chinese web site (which of course is bloody hard to find because
it's not properly indexed / search-engine-referenced) but if you _do_
find one let me know as the speed is quite quick from here.

l.

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

[Luke Kenneth Casson Leighton]

http://www.chrontel.com/index.php/products/display-interface/ch7034-hdtv-vga-lvds-encoder

oo! that one!

hey i recognise that one, i'm certain it was the IC used in the
GPL-violating CTPC89e, all those years ago.

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

[Luke Kenneth Casson Leighton]

http://download.csdn.net/detail/jangel_lee/6854539

*hurls*. anyone know how to extract files from that crapsite?

l.

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

[Christopher Havel]

Using the F12 console in Chromium... I don't see that there's even a PDF
behind that thing. I honestly cannot tell how that flash player document
viewer thing is generating or retrieving its content.

...never mind, I'm blind as a bat.

There's a blue download button underneath the black magic document viewer,
which takes you to --> http://download.csdn.net/download/jangel_lee/6854539

If you click the ORANGE button on that download page, the one with the
star-in-circle icon, you may be able to get in through there. Clicking it
brings up a dialog box for a login. In there, there's a set of four tiny
icons. Second-in-from-right tiny icon is a Github logo. Click that and, if
you've a Github account, you can probably get through. I have one such
account, but (as is often the case with me) I've long since forgotten my
login credentials entirely... so, good luck.

There also appears to be a pay-us-money option... the "VIP" GREEN button
below the other three.

[Luke Kenneth Casson Leighton]

jan: y'did ok. you started a great conversation where it'll result in
improvements to the EOMA68 standard. the subject line is telling,
however: "the only way". that's inflexibility which is going to end
in tears. there's... well... there's _usually_ more than one way :)
you did ok taking in a huge number of factors... just not enough of
them. still appears to be my role to do that... *sigh*... take it
easy, ok?

l.

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

[Luke Kenneth Casson Leighton]

Post by Christopher Havel
Using the F12 console in Chromium... I don't see that there's even a PDF
behind that thing. I honestly cannot tell how that flash player document
viewer thing is generating or retrieving its content.

ah: you reminded me, there might be a way to examine the network
traffic, see what the fuckwit adobe plugin is doing, and extract the
specific file / request.

l.

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

[dumblob]

Hi guys,

I waited for the thread to settle down - so, first, thank you for calming
down.

This thread simply just approved what I've been most afraid of. Namely all
the information channels regarding EOMA make up to a one big mess.

I'll follow now this process:

1) I'll gather all valid information about current EOMA (as quite a few
pieces are invalid, incomplete or at least misleading) through thorough
asking on this list.

2) I'll add (new) information from my side and make absolutely sure you all
understand it (including context and background).

3) I'll restate, rewrite, propose again a solution to what I see as a
bottle neck.

4) We'll all finally react upon the point 3 and discuss the steps to
resolve each particular bottle neck.

Regards,

-- Jan