E-ink Screen

[thatgui]

I don't really see that as a point of failure. If the lid is designed correctly, there should be no problems that could arise.

Why doesn't that argument apply to "switch to change audio jack layout" argument?But to get more specific:

- stability of the lid

- stability of the mechanical connection between lid and display itself

- problems that arise if you want to integrate it in the lid in a way that the surface is plane (otherwise you will get a "dirt catcher")

- And after watching the specific part of the video you linked to: blunt/stumped force resistance is nice, but what about force that is more concentrated on one point (like keeping it in a bag with other things, falling onto something) ?.

Don't get me wrong I would like a second eInk screen, but I don't think its feasible to include it.

Edit: Anyone got any infos wether yota devices uses an additional layer of protection (like some thin plastic cover) for the eInk display ?

 

[Eight Bit]

An E-Ink screen on the lid would be awesome and a welcome addition imo! 

I can see the Pyra being a replacement for:

Portable computer,

Phone,

Handheld game system,

Tablet,

E-Reader,

Remote control (Was an IR LED planned?)

Portable Music/Media player,

Snapshot camera/video conferencing system,

Navigation system

What else? ^^

If the Pyra could do all that, why would I need any other devices anymore?

All that and upgradable too...

 

[God Ginrai]

- stability of the lid

The lid should be fine, there is still plenty of plastic that would be left to create a stable frame.

- stability of the mechanical connection between lid and display itself

Do you mean what holds it in place? This shouldn't be different than holding in place the screen for any cell phone.

- problems that arise if you want to integrate it in the lid in a way that the surface is plane (otherwise you will get a "dirt catcher")

Well, since you can use capacitive display technology with it, (or not even have touch on it) that should hardly be a problem. If you notice, the Yotaphone doesn't have a bezel.

- And after watching the specific part of the video you linked to: blunt/stumped force resistance is nice, but what about force that is more concentrated on one point (like keeping it in a bag with other things, falling onto something) ?.

e-ink has a page about the ruggedness of their displays. While it doesn't really explain much on its own, it does have a video on the top of the page that is rather enlightening. The person in the video tries to see what happens when he bends the screen, takes a knife to it, burns it, and even drills into it with a power drill. It performed admirably better than an LCD would under the same circumstances. The knife wasn't really able to do anything to the display, and the first hole made with the power drill stopped part of the display, but the second 2 didn't effect it at all, even the parts they were drilled through.

Sadly this wasn't a youtube video, so I couldn't just embed the video here. Here's the link to the page that has the video on it: http://www.eink.com/rugged.html

Edit: Anyone got any infos wether yota devices uses an additional layer of protection (like some thin plastic cover) for the eInk display ?

Their spokesperson said they don't like layers between the screen and the user, so I doubt it does.

Also, does anyone know who makes the e-ink screens used on the back of the Yotaphone? We should look into that for sourcing. The screen on the Yotaphone seems to be just the right size for our purposes.

-God Ginrai

 

[Batou456]

I like this idea.

Touch layers tend to not make sense with an e-ink display as they tend to add to glare issues, so it could be behind a pane of clear plastic/reinforced glass if needed.  If you want to get fancy with a pair of small LEDs and a PWM circuit to light the e-ink screen from the front in an adjustable manner.

Last I heard the idea was to use a kind of rocker switch for the shoulder buttons to allow for 4 shoulder buttons.  I could in turn see these being easily configured so one shoulder rocker switch operates as a menu switch.  Thus allowing things like switching between a configured list of lid screen programs.   While the other shoulder button rocker could allow for contextual switching between things like song tracks or pages in a book.

 

[God Ginrai]

I like this idea.

Touch layers tend to not make sense with an e-ink display as they tend to add to glare issues, so it could be behind a pane of clear plastic/reinforced glass.  If you want to get fancy with a pair of small LEDs and a PWM circuit to light the e-ink screen from the front in an adjustable manner.

Last I heard the idea was to use a kind of rocker switch for the shoulder buttons to allow for 4 shoulder buttons.  I could in turn see these being easily configured so one shoulder rocker switch operates as a menu switch.  Thus allowing things like switching between a configured list of lid screen programs.   While the other shoulder button rocker could allow for contextual switching between things like song tracks or pages in a book. 

Hence there doesn't appear to be much need to have the e-ink screen exposed, and most durability issues can be avoided although this would add additional costs and lid design complexity.

Well, I wouldn't mind having capacitive touch, but as I said before. I don't need touch for the screen to be useful for me.

Also, you haven't read much about the shoulders, then, because the rocker was simply suggested by a member of the community (Grench, I think) and is not the way they will work. EvilDragon has specifically said he will implement them in the same way as Askarus's four-shoulder button mod for the Pandora. This means they will be one on top of the other.

Also, If there is no touch screen, I'd much rather open the device to change what shows on the lid screen. If you tie it to the shoulder buttons, you take the ability for other applications (such as media players) to make good use of those buttons while the device is closed.

-God Ginrai

 

[Batou456]

I don't have the time to follow that much, but that's a better situation.

If it's 4 distinct buttons then you have the opportunity to setup 4 direct function calls, 4 easy 2 button combos, 12 less straightforeward 2 button combos, and a 4 button push.  There's also 3 button push options if someone wanted someing more obscure then say a 4 button push for shifting it to app selection mode.

That's a lot of options without having to assign things to actions like double clicking.  As a result I don't see a limitation in terms of the button options, or a reason to hamstring what you can do with the back screen by not allowing what is effectively native app switching while closed.  I can easily see someone for instance wanting to check the time/their calendar while playing their music.  Or wanting to listen to music while reading a book, and having the option to context switch without having to open the Pyra.

 

[ZetaNeta]

Dual screen, when they are unequal (One screen is meant for other stuff than the other one), requires to develop totally new interfaces, and is not readily available in Linux. (Except when it goes to console... but we are talking about a graphical enviroment here?)
Writing drivers, developing for what e-ink can and cannot, developing interfaces..... No, this is too useless for too much.

 

[God Ginrai]

Dual screen, when they are unequal (One screen is meant for other stuff than the other one), requires to develop totally new interfaces, and is not readily available in Linux. (Except when it goes to console... but we are talking about a graphical enviroment here?)

Writing drivers, developing for what e-ink can and cannot, developing interfaces..... No, this is too useless for too much.

Honestly, I believe you're over-complicating things. There should not be much difference between making use of one screen or the other in code. It would likely just be accessing different framebuffers.

You may be right that drivers will have to be written, but that's the only amount of effort that is needed. And we have mentioned tons of uses for this screen. This screen would hardly be useless.

-God Ginrai

 

[ZetaNeta]

Dual screen, when they are unequal (One screen is meant for other stuff than the other one), requires to develop totally new interfaces, and is not readily available in Linux. (Except when it goes to console... but we are talking about a graphical enviroment here?)


Writing drivers, developing for what e-ink can and cannot, developing interfaces..... No, this is too useless for too much.

Honestly, I believe you're over-complicating things. There should not be much difference between making use of one screen or the other in code. It would likely just be accessing different framebuffers.


You may be right that drivers will have to be written, but that's the only amount of effort that is needed. And we have mentioned tons of uses for this screen. This screen would hardly be useless.

-God Ginrai

Framebuffers are framebuffers... But those are 2 displays, which does different function.


If 2 displays, which "extent" eachother are "equal", the displays which do 2 different things are "unequal", and this way is a "dark road" in the world of Linux GUI.


1 screen should always be a "True Linux", on which Xorg will run. The other screen will be purely a Pyra addon, which.... who will support it? I know that a strong community will do a strong support, but apart from asking "Where you see it?", even strong communities fail doing it ways similar to this.


Only way to save it is to turn it into pure console, and let the true "BASH scripting" maniacs like me to make use of it... This will let most users develop/customize it straight away. Atleast the ones who know any scripting language or python/perl.


But.... still i find it very useless.


Imagine you self, having a pyro, and trying to find a real use for this.... What exactly is hard in opening the screen, which is what you hands remember from the last 9000 folding device, and what you are going to do "by mistake" the first week of using it?


A e-ink screen is a one-time-use thing, about which you are going to forget real quick.


I look at this as at a serious waste of money.

 

[God Ginrai]

First of all, 2 screens can run separate X servers. I don't see the problem.

And second, who said we need X for the second screen? We didn't need X on the GP2X to develop games for it. As I said, you are over-complicating things.

We have a community of competent developers who could easily make use of this screen.

-God Ginrai

 

[bzar]

I always assumed the second screen would be a dumb framebuffer device to just pop images on. Of course apps would have to support it explicitly, but I don't think it would be unused at all.

 

[ZetaNeta]

First of all, 2 screens can run separate X servers. I don't see the problem.


And second, who said we need X for the second screen? We didn't need X on the GP2X to develop games for it. As I said, you are over-complicating things.


We have a community of competent developers who could easily make use of this screen.

-God Ginrai

No one is saying we will have X on the second screen... this is more than nonsense.


Still i doubt the screen will be used much.


And again, i see a serious waste of money, and solidness of the console in the face of the e-ink screen.

I always assumed the second screen would be a dumb framebuffer device to just pop images on. Of course apps would have to support it explicitly, but I don't think it would be unused at all.

Are we still talking about e-ink? Images aren't very good on e-ink...


And yes, the thing that the apps would need to support it explicitly, and that may pose a serious threat of uselessness to it.


From another side, we may implement the widely used Desktop Notifications Specification (Notifications basically) to communicate with the server, which will render them to the e-ink.


This would first of all let several applications use the screen, instead of a single app taking the entire screen for it self.


Secondary, this would integrate into the existing Linux applications.


But i still see minimal use in it. Its a "play, play, and leave it" feature for me.

 

[God Ginrai]

No one is saying we will have X on the second screen... this is more than nonsense.

I'm sorry, the way you were suggesting that only BASH would work well on it and that the main screen would run Xorg made it seem like you were deriding it for being unable to have X.

Still i doubt the screen will be used much.

I believe quite the opposite. There are tons of uses for such a screen, and if it is as simple as using another framebuffer to put things on it, I find it highly unlikely that other developers would not take advantage of it.

And again, i see a serious waste of money, and solidness of the console in the face of the e-ink screen.

 I've already pointed out multiple times that these screens are incredibly rugged. I don't see grounds for your claim that this hurts the solidness of the console.

I always assumed the second screen would be a dumb framebuffer device to just pop images on. Of course apps would have to support it explicitly, but I don't think it would be unused at all.

 Are we still talking about e-ink? Images aren't very good on e-ink...

Images are just fine on e-ink. You just don't have color.

And yes, the thing that the apps would need to support it explicitly, and that may pose a serious threat of uselessness to it.

And developers would use it. Hence, it would not be useless.

From another side, we may implement the widely used Desktop Notifications Specification (Notifications basically) to communicate with the server, which will render them to the e-ink.

This would first of all let several applications use the screen, instead of a single app taking the entire screen for it self.

Secondary, this would integrate into the existing Linux applications.

That's an interesting idea. I still would want applications to be able to use the e-ink screen on their own, but there may be a way to have a setting that you could toggle that would make the e-ink screen be updated with this information whenever not in use by an application.

-God Ginrai

 

[bzar]

Are we still talking about e-ink? Images aren't very good on e-ink...

I meant images as in bitmaps. Anything we want to display on it. Not photographs and stuff. Pixel arrays.

 

[Kiga]

5 dollars 4.3 inch screen here: http://oedtech.com/English/index.aspx

 

[ZetaNeta]

No one is saying we will have X on the second screen... this is more than nonsense.

I'm sorry, the way you were suggesting that only BASH would work well on it and that the main screen would run Xorg made it seem like you were deriding it for being unable to have X.

Still i doubt the screen will be used much.

I believe quite the opposite. There are tons of uses for such a screen, and if it is as simple as using another framebuffer to put things on it, I find it highly unlikely that other developers would not take advantage of it.

And again, i see a serious waste of money, and solidness of the console in the face of the e-ink screen.

 
I've already pointed out multiple times that these screens are incredibly rugged. I don't see grounds for your claim that this hurts the solidness of the console.

I always assumed the second screen would be a dumb framebuffer device to just pop images on. Of course apps would have to support it explicitly, but I don't think it would be unused at all.

 
Are we still talking about e-ink? Images aren't very good on e-ink...

Images are just fine on e-ink. You just don't have color.

And yes, the thing that the apps would need to support it explicitly, and that may pose a serious threat of uselessness to it.

And developers would use it. Hence, it would not be useless.

From another side, we may implement the widely used Desktop Notifications Specification (Notifications basically) to communicate with the server, which will render them to the e-ink.


This would first of all let several applications use the screen, instead of a single app taking the entire screen for it self.


Secondary, this would integrate into the existing Linux applications.

That's an interesting idea. I still would want applications to be able to use the e-ink screen on their own, but there may be a way to have a setting that you could toggle that would make the e-ink screen be updated with this information whenever not in use by an application.

-God Ginrai

Xorg is nonsense, as most applications using Xorg also (as a rule) utilizes colors and some very advanced functions.


I mean that we should do something very easy for the user to "make him self".


So i said about putting just a linux TTY there. And after that, it will be very easy even for a idiot to do something. This would pour more life into it.


Otherwise, we can go the way i suggested with notification daemon... Or do something "Conky-like". Would be perfect if it would be a modified version of Conky itself.


Of course if you put it, it would be a waste of this screen if developers would not use it.... But one thing is when developers are in demand of this, and actually have ideas to do there. And another thing when you press youself to think what to put there?


(Here, you idea of using it only when needed may be useful, but does not cover that completely)


I just dont wanna it to repeat the way of 3DS. 3D is cool, yet, you cant use it for normal business, and surely should never even put it in the list of the main features.


Its a portable computer not hunting for "market dominating", not a console. (Marketed as one, but not a console actually. Not really.)


I may be totally wrong. I just checked prices (before Kiga ninjad while i been writing this) and gone with the fact that: "A useless function priced below the dirt should still be included" :3


Again, i cant predict the future... Maybe it will be really useful. Who knows?

 

[WizardStan]

5 dollars 4.3 inch screen here: http://oedtech.com/English/index.aspx

I'm trying to figure out where you saw that price and far more importantly where I can buy one!

 

[Kiga]

Here (in the comments):http://www.the-digital-reader.com/2013/02/07/ereaders-with-knockoff-e-ink-screens-now-available-in-multiple-sizes-4-3-6-8/

Apparently it is made by reverse engineering but there is not law infringement

 

 

[WizardStan]

Comments say "$5-$10 cheaper", not that they will cost $5-$10. Still, $15 instead of $20 isn't bad.

 

[God Ginrai]

5 dollars 4.3 inch screen here: http://oedtech.com/English/index.aspx

Awesome. Not to mention, if EvilDragon contacted e-ink themselves, they may be more than willing to set him up with good prices and support through themselves or one of their partners. They are really trying to push this second-screen idea for devices to try to get e-ink onto devices that until this point have been ruled by LCD, so I think they would be more than interested in selling to us.

EDIT:

@ZetaNeta: You literally started another topic about having an LCD in the same place as this e-ink screen. This would be more fragile than the e-ink screen and wouldn't offer the benefits that the e-ink screen does. (sunlight readable, low power consumption)

-God Ginrai