[Arm-netbook] Question about resolution on the micro-desktop

[Julie Marchant]

Hey, I'm wondering something.

So, one of the features of the micro-desktop is a VGA port. I assume
that it's probably connected to the RGB/TTL, right? And the page on the

The maximum RGB/TTL resolution permitted is 1366 x 768.

So then, does that mean that the VGA port on the micro-desktop is
limited to resolutions no larger than this?

[dumblob]

Hi Julie,

yes (even though in the upcoming specification version 1920x1080 should be
supported).

Note though, that disregarding the resolution, the colors depth is always
just 6 bits (instead of the standard 8 bits). No change to this is planned
for the PCMCIA form factor based EOMA specifications (I'm actually really
curious whether Luke will have some success with Amphenol with regards to
finding another suitable form factor for the future high-end EOMA spec
version which doesn't exist yet; this another form factor needs to be
physically incompatible with all PCMCIA size variants to avoid swapping
wrong cards).

Kind regards,

-- Jan

[Luke Kenneth Casson Leighton]

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

Post by dumblob
Hi Julie,
yes (even though in the upcoming specification version 1920x1080 should be
supported).

NO. it's NEGOTIATED. if the HOUSING supports it AND the Card
supports it, 1920x1080 is ALLOWED. but to do that, the Housing MUST
be capable of simultaneously supporting 1366x768 *AND* beyond. in the
case of fixed LCDs, the only way to guarantee that is to have line (or
frame) buffer upscaler ICs *ON THE HOUSING*.

it's NOT as simple as "1920x1080 is supported, period".

Post by dumblob
Note though, that disregarding the resolution, the colors depth is always
just 6 bits (instead of the standard 8 bits). No change to this is planned
for the PCMCIA form factor based EOMA specifications

nope

Post by dumblob
(I'm actually really
curious whether Luke will have some success with Amphenol with regards to
finding another suitable form factor for the future high-end EOMA spec
version which doesn't exist yet; this another form factor needs to be
physically incompatible with all PCMCIA size variants to avoid swapping
wrong cards).

doesn't have to be amphenol. any mass-volume connector will do.
MiniPCIe was also something i considered in the past, but finding a
right-angle "slotted" connector like the old games consoles proved
elusive. and also i was concerned about accuracy of mating, and about
having to create a surround shield custom casework.... look at the
intel card you'll see what they did. that cost tens of thousands of
dollars in tooling costs to make.


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 Luke,

Post by dumblob
in the
case of fixed LCDs, the only way to guarantee that is to have line (or
frame) buffer upscaler ICs *ON THE HOUSING*.

I think there was another discussed solution not requiring "anything" (not
even line buffer upscaler IC) on the housing. Namely just drawing the small
resolution directly to the higher-resolution display to the edge where the
signal starts drawing the first line). Did you abandon it? If yes, then why?

Post by dumblob
it's NOT as simple as "1920x1080 is supported, period".

Well, in the spec on
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware it
says for PCMCIAv2 and PCMCIAv3 "maximum RGB/TTL resolution permitted is
1366 x 768" which clearly disallows any negotiation. Could you please
correct these statements on the wiki page?

Also, if all the housings must support the rates of 1366x768, then I would
say it's too much. One can find devices like small netbooks or tablets or
special-purpose devices like projectors, but mainly TVs with resolutions
starting at ***@60 (***@30). For all these mass production will
continue for at least the next few years. During these years EOMA HW should
spread also to these domains.

doesn't have to be amphenol. any mass-volume connector will do.

Post by dumblob
MiniPCIe was also something i considered in the past, but finding a
right-angle "slotted" connector like the old games consoles proved
elusive. and also i was concerned about accuracy of mating, and about
having to create a surround shield custom casework.... look at the
intel card you'll see what they did. that cost tens of thousands of
dollars in tooling costs to make.

Any tips for other 45-70 pins connectors with physical size similar to
PCMCIA and being suitable for a possible high-end EOMA spec (maybe
utilizing PCI Express link(s) instead of one of the USBs in EOMA68, maybe
MIPI DSI instead of RGB/TTL, maybe 18W dissipation like the lowest MXM,
etc.)? On http://elinux.org/Embedded_Open_Modular_Architecture there is no
such connector. Something like M2 for "big computing" (i.e. made physically
robust (incl. full coating) and freed from stuff like ADC pins, 10 GND
pins, etc.). What caught my eye is, that M2 actually does not limit thermal
dissipation at all.

You tried to contact many manufacturers and companies. Did you happen to
contact also M2 creators?

By the way, could you ask administrators of elinux.org to set up either
mod_rewrite in Apache (or equivalent in nginx or whatever server they use)
or at least disallow/blacklist pages with traling slash in their name?

Currently if one goes to
http://elinux.org/Embedded_Open_Modular_Architecture/ , it's empty, but
removing the trailing slash gets one to the correct page. This is very
confusing (see https://phabricator.wikimedia.org/T14703 and
https://bugzilla.mozilla.org/show_bug.cgi?id=961132 ) and therefore e.g.
wikipedia is also redirecting to a page without slash (try e.g.
https://en.wikipedia.org/wiki/Main_Page/ ).

Kind regards,

-- Jan

[Julie Marchant]

Post by dumblob
Also, if all the housings must support the rates of 1366x768, then I
would say it's too much.

I think it's obvious that's not what the standard says. It says that the
*card* must support 1366x768. That's very different from requiring the
*display* to support 1366x768. The only thing the display is required to
do is support a resolution within the range the cards are required to
support, so you can't have a type II housing that is only capable of
displaying at 1920x1080. But having a type II housing that is only
capable of displaying at 800x480 would be perfectly fine.

[Luke Kenneth Casson Leighton]

Post by Julie Marchant

Post by dumblob
Also, if all the housings must support the rates of 1366x768, then I
would say it's too much.

I think it's obvious that's not what the standard says. It says that the
*card* must support 1366x768. That's very different from requiring the
*display* to support 1366x768. The only thing the display is required to
do is support a resolution within the range the cards are required to
support, so you can't have a type II housing that is only capable of
displaying at 1920x1080. But having a type II housing that is only
capable of displaying at 800x480 would be perfectly fine.

*thinks*.... yes that's all completely correct.

so. version 1 of the standard says, housings can go *up* to 1366x768.

version 2 (yet to be written up) says, if housings *WANT* to go over
1366x768, they MUST be prepared to provide hardware-level scaling so
that CARDS which only support up to 1366x768 may say to the Housing:
"yep, i only do 1366x768: your responsibility to deal with that".

if you plug in an HDMI monitor (which has auto-scaling) it's fine: a
version 1 Card can go "i'll take native 1366x768 over upscaled
1366x768-1920x1080, thank you" but for something like a laptop or
all-in-one PC where the LCD has a fixed resolution of say 1600x900 or
1920x1080, that's where hardware-level scaling would kick in.

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.ph

[Luke Kenneth Casson Leighton]

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


On Fri, Jan 13, 2017 at 6:56 PM, Benson Mitchell

Post by dumblob
Hi Luke,

Post by dumblob
in the
case of fixed LCDs, the only way to guarantee that is to have line (or
frame) buffer upscaler ICs *ON THE HOUSING*.

I think there was another discussed solution not requiring "anything" (not
even line buffer upscaler IC) on the housing. Namely just drawing the small
resolution directly to the higher-resolution display to the edge where the
signal starts drawing the first line).
Seems to me it's not that simple -- displays not only require a specific
resolution, but a specific timing. To display a 1366x768 output unscaled on
(1) Compatible timings -- the 1366x768 output must have the same horizontal,
vertical, and pixel frequencies as the 1920x1080 display expects. In
essence, the "1366x768" signal is *identical* to a 1920x1080 signal, with
black bars on some or all edges.
(2) Rescaling hardware -- in general, this means a full frame buffer,
whether the vertical frequencies match or not. In specific cases where the
vertical frequencies and the horizontal frequencies match, you can use a

ohhh that explains why chrontel do both line buffer and frame buffer
scaling ICs.

Post by dumblob
(Obviously, if you've got a third approach, do tell us!)

i haven't!

hmmm.... y'know... i believe it reasonable to assume that the output
hardware is sufficiently flexible to be able to arbitrarily scale the
vertical, horizontal, clock frequencies, sync pulses and more.

heck, even the opencores.org VGA/LCD controller which was borrowed
and used in the ICubeCorp IC1t is capable of all that.

i really _really_ appreciate you bringing this up, though, as it's
going to be important to mention in the notes.

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

[Luke Kenneth Casson Leighton]

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

Post by Julie Marchant
Hey, I'm wondering something.
So, one of the features of the micro-desktop is a VGA port.

correct.

Post by Julie Marchant
I assume that it's probably connected to the RGB/TTL, right?

correct. the PDFs of the schematics are available for anyone to confirm that.

Post by Julie Marchant
And the page on the

The maximum RGB/TTL resolution permitted is 1366 x 768.

correct.

Post by Julie Marchant
So then, does that mean that the VGA port on the micro-desktop is
limited to resolutions no larger than this?

that's incorrect. you're perfectly entitled to try resolutions
beyond that which are required by the EOMA68 specification (however do
not be surprised if it doesn't actually work).

in the case of the A20 Card, the RGB/TTL output *happens* to be
capable of driving up to 1920x1080 @ 60fps, which happens to be well
beyond what i would expect the PCMCIA interface to cope with without
creating EMF interference (which will be your problem to deal with if
you go beyond the specification).

but all of this doesn't make sense - these "arbitrary-seeming"
restrictions - make absolutely no sense until one SoC *happens* to be
encountered that is *NOT* capable of greater than 1366x768. which is
not *right now* but will occur in the future.

bottom line: if you develop an app that violates the EOMA68
specification, then your clients all upgrade (without telling you) to
a future card and they *ALL* complain "your app dun't wurk no more",
don't come crying to me :)

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.phco

[Julie Marchant]

Post by Luke Kenneth Casson Leighton
that's incorrect. you're perfectly entitled to try resolutions
beyond that which are required by the EOMA68 specification (however do
not be surprised if it doesn't actually work).
in the case of the A20 Card, the RGB/TTL output *happens* to be
beyond what i would expect the PCMCIA interface to cope with without
creating EMF interference (which will be your problem to deal with if
you go beyond the specification).

Ah, OK then.

So what does it look like on the side of the OS? If you're using a 1080p
monitor and it turns out that the card is capable of 1080p through
RGB/TTL, does the OS automatically know this, or does it still think
(without manual intervention) that some smaller resolution like 1366x768
is the maximum?

Post by Luke Kenneth Casson Leighton
bottom line: if you develop an app that violates the EOMA68
specification, then your clients all upgrade (without telling you) to
a future card and they *ALL* complain "your app dun't wurk no more",
don't come crying to me :)

Right, I was wondering more from the perspective of the end-user. The
main reason I'm wondering is because the monitor my mom currently uses
has a native resolution of 1280x1024 (one of those old monitors from
around 2000 or so).

[Luke Kenneth Casson Leighton]

Post by Julie Marchant

Post by Luke Kenneth Casson Leighton
that's incorrect. you're perfectly entitled to try resolutions
beyond that which are required by the EOMA68 specification (however do
not be surprised if it doesn't actually work).
in the case of the A20 Card, the RGB/TTL output *happens* to be
beyond what i would expect the PCMCIA interface to cope with without
creating EMF interference (which will be your problem to deal with if
you go beyond the specification).

Ah, OK then.
So what does it look like on the side of the OS?

that's entirely going to depend on what OS and what Card you have.

Post by Julie Marchant
If you're using a 1080p
monitor and it turns out that the card is capable of 1080p through
RGB/TTL, does the OS automatically know this, or does it still think
(without manual intervention) that some smaller resolution like 1366x768
is the maximum?

i'm not going to make any such restrictions in software. if someone
plugs in a 1080p VGA monitor, and through the EDID interface it's
detected, and the OS and the SoC is capable of it, good for them.

the problem comes if they then *rely* on that... hmmm...

Post by Julie Marchant

Post by Luke Kenneth Casson Leighton
bottom line: if you develop an app that violates the EOMA68
specification, then your clients all upgrade (without telling you) to
a future card and they *ALL* complain "your app dun't wurk no more",
don't come crying to me :)

Right, I was wondering more from the perspective of the end-user. The
main reason I'm wondering is because the monitor my mom currently uses
has a native resolution of 1280x1024 (one of those old monitors from
around 2000 or so).

yeah that miiight be okay... it's a full 30% higher than the EOMA68
spec (in terms of the number of pixels) so is definitely out-of-spec,
but you might get lucky.

l.

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

[Lyberta]

Post by Luke Kenneth Casson Leighton
i'm not going to make any such restrictions in software. if someone
plugs in a 1080p VGA monitor, and through the EDID interface it's
detected, and the OS and the SoC is capable of it, good for them.

And what if there is no EDID?

[Adam Van Ymeren]

Post by Lyberta

Post by Luke Kenneth Casson Leighton
i'm not going to make any such restrictions in software. if someone
plugs in a 1080p VGA monitor, and through the EDID interface it's
detected, and the OS and the SoC is capable of it, good for them.

And what if there is no EDID?

Then you're using a really esoteric display and you'll have to
manually configure the modes in your software.

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

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

[Christopher Havel]

There's also the matter of cheap VGA cables that have a physical pin 12 on
the connectors that is not internally attached to anything at either end.

I have a couple of those cables :( they do a very good job of disabling
EDID.

[Christian Kellermann]

Post by Adam Van Ymeren

Post by Lyberta

Post by Luke Kenneth Casson Leighton
i'm not going to make any such restrictions in software. if someone
plugs in a 1080p VGA monitor, and through the EDID interface it's
detected, and the OS and the SoC is capable of it, good for them.

And what if there is no EDID?

Then you're using a really esoteric display and you'll have to
manually configure the modes in your software.

From my experience there are a *lot* of monitors out there with a
strange understanding of the EDID standard. But if that fails linux
will do a lot of guesswork to get it right, or you would have to
manually fiddle with it.

EDID is also one of the many standards that I have written that
contradict themselves on the *same* page several times...

And it is behind the big scary NDA wall so one cannot verify any of my
claims of course...

Cheers,

Christian

--
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

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

[Luke Kenneth Casson Leighton]

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

Post by Lyberta

Post by Luke Kenneth Casson Leighton
i'm not going to make any such restrictions in software. if someone
plugs in a 1080p VGA monitor, and through the EDID interface it's
detected, and the OS and the SoC is capable of it, good for them.

And what if there is no EDID?

standard procedure required which was established in windows 95 some
decades ago: start with low resolution, change to higher with 10
second reversion delay and a dialog box "is this resolution ok yes
no".

l.

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

[Christopher Havel]

1280x1024 is the very much standard resolution for a non-widescreen (4:3
aspect ratio) 17" monitor. It's actually still fairly common, I'd say... I
have IIRC three monitors like that... two HP LCDs, and an old (~2006)
eMachines "flatscreen" CRT boat anchor. That CRT monitor is heeeeaaaavy. It
works, mind you... but it's a real lunker. Kinda funny... when they say
"flatscreen" they don't mean LCD, they mean that the front of the CRT is
flat and not curved... it's kinda weird.

FWIW, my mother's computer's monitor is a Samsung 510MP... 15" XGA. Which
is to say -- 1024x768, with a 4:3 aspect ratio. She absolutely will not use
anything bigger or different because to her, it's perfect. Who am I to
argue... ;)

[Julie Marchant]

Post by Christopher Havel
1280x1024 is the very much standard resolution for a non-widescreen (4:3
aspect ratio) 17" monitor.

1280x1024 is 5:4, not 4:3.

Not terribly important for what you're saying, but I just wanted to
point that out. ;)

[Christopher Havel]

Post by Julie Marchant

Post by Christopher Havel
1280x1024 is the very much standard resolution for a non-widescreen (4:3
aspect ratio) 17" monitor.

1280x1024 is 5:4, not 4:3.

Oh, whoops... sorry about that! *blush*

They, er, look pretty similar to each other, width-to-height-wise.
Obviously I can't tell the difference!

[Luke Kenneth Casson Leighton]

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

Post by Julie Marchant

Post by Christopher Havel
1280x1024 is the very much standard resolution for a non-widescreen (4:3
aspect ratio) 17" monitor.

1280x1024 is 5:4, not 4:3.
Not terribly important for what you're saying, but I just wanted to
point that out. ;)

:)

Post by Julie Marchant

Post by Christopher Havel

1280*1024

1310720

Post by Julie Marchant

Post by Christopher Havel

1366*768

1049088

Post by Julie Marchant
--
Julie Marchant
https://onpon4.github.io
https://emailselfdefense.fsf.org
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

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