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 EOMA68 standard states:
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?
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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jan 13, 2017 at 3:07 PM, dumblob dumblob@gmail.com wrote:
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".
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
(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.
Hi Luke,
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?
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 704x240@60 (704x480@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.
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
On 01/13/2017 12:30 PM, dumblob wrote:
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.
On Fri, Jan 13, 2017 at 5:48 PM, Julie Marchant onpon4@riseup.net wrote:
On 01/13/2017 12:30 PM, dumblob wrote:
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.
On Jan 13, 2017 12:31 PM, "dumblob" dumblob@gmail.com wrote:
Hi Luke,
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 a 1920x1080 display requires one of two things: (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 single line buffer. For example, displaying a 960x1080@60Hz screen on half of a 1920x1080@60Hz screen. (Obviously, if you've got a third approach, do tell us!)
(1) is actually possible in some cases, where the output's limitation is related to the RAM available for framebuffer, rather than the timing, but can't be relied on in general. The pixel clock will be the most critical limit for some Type II CPU cards, so every Type II housing _must_ accept a 1366x768 (or less) signal, _at_ standard timings (or slower) -- demanding low-res display at 1920x1080 timings means some CPU cards simply plug in and don't work, and that's unacceptable.
(2) could work, at least with a full frame buffer -- for the one-line hack, I'm not sure if weird modes like 960x1080 are allowed -- the pixel clock and vertical frequencies are essentially the same as 1366x768, but the horizontal frequency is higher. The new revision of the spec that covers negotiation will no doubt make it clear.
But it doesn't matter, as it's obviously worse than direct scaling; there we only need a full frame for mismatched vertical frequency (so don't do that!), and otherwise only needs a two or three line buffer; to most people, I'm sure it's worth the slight extra cost to have 1366x768 on the full screen, rather than 960x1080 on half of the screen.
Benson
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jan 13, 2017 at 6:56 PM, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
On Jan 13, 2017 12:31 PM, "dumblob" dumblob@gmail.com wrote:
Hi Luke,
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 a 1920x1080 display requires one of two things: (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 single line buffer. For example, displaying a 960x1080@60Hz screen on half of a 1920x1080@60Hz screen.
ohhh that explains why chrontel do both line buffer and frame buffer scaling ICs.
(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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jan 13, 2017 at 2:52 PM, Julie Marchant onpon4@riseup.net wrote:
Hey, I'm wondering something.
So, one of the features of the micro-desktop is a VGA port.
correct.
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.
And the page on the EOMA68 standard states:
The maximum RGB/TTL resolution permitted is 1366 x 768.
correct.
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.
On 01/13/2017 10:42 AM, Luke Kenneth Casson Leighton wrote:
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).
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?
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).
On Fri, Jan 13, 2017 at 4:19 PM, Julie Marchant onpon4@riseup.net wrote:
On 01/13/2017 10:42 AM, Luke Kenneth Casson Leighton wrote:
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).
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.
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...
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.
On Fri, Jan 13, 2017 at 8:39 PM, Lyberta lyberta@lyberta.net wrote:
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.
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
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.
* Adam Van Ymeren adam.vany@gmail.com [170114 04:49]:
On Fri, Jan 13, 2017 at 8:39 PM, Lyberta lyberta@lyberta.net wrote:
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Jan 14, 2017 at 1:39 AM, Lyberta lyberta@lyberta.net wrote:
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.
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... ;)
On 01/13/2017 11:26 AM, Christopher Havel wrote:
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. ;)
On Fri, Jan 13, 2017 at 11:38 AM, Julie Marchant onpon4@riseup.net wrote:
On 01/13/2017 11:26 AM, Christopher Havel wrote:
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!
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jan 13, 2017 at 4:38 PM, Julie Marchant onpon4@riseup.net wrote:
On 01/13/2017 11:26 AM, Christopher Havel wrote:
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. ;)
:)
1280*1024
1310720
1366*768
1049088
-- Julie Marchant https://onpon4.github.io
Protect your emails with GnuPG: https://emailselfdefense.fsf.org
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
arm-netbook@lists.phcomp.co.uk
-
Adam Van Ymeren -
Benson Mitchell -
Christian Kellermann -
Christopher Havel -
dumblob -
Julie Marchant -
Luke Kenneth Casson Leighton -
Lyberta