Hi, today I was able to invest some time to look again into the MIPI panel issue.
The PWM backlight output is actively driven to low by the panel. This means that I have backlight voltage if I program the OMAP5 with a pull-up and have no panel connected. If I connect the panel, the signal is 0V actively turning off the backlight. This can only be driven by the panel.
So the question is as simple: which knobs turn on the backlight?
To simplify further experiments I have added a /sys interface to the R63311 driver [1] so that I can send arbitrary commands and read back values.
It works e.g. as this:
echo 51ff >/sys/devices/ocp.3/dss.10/0.dsi/display0/dcs should send 0x51 0xff and turn backlight to full intensity
or
echo 52r >/sys/devices/ocp.3/dss.10/0.dsi/display0/dcs should send a read command 0x52 and read 1 byte back
The interesting thing is that I can really find out that register 52 returns two bytes (0x0000 = backlight permanently off) because 52r and 52rrr fails. But I can't see the value written by the 51 command :(
And if I write 0xffff to 51 the panel controller appears to hang. So this might be an invalid value which locks up the R63311.
I think the panel communication really works - but we are still missing the interpretation of the bit patterns in the max. 255 registers/commands.
So the next step is to do some trial&error on that...
BR, Nikolaus
[1]: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=0...
Am 14.02.2014 um 18:15 schrieb Dr. H. Nikolaus Schaller:
Hi, today I was able to invest some time to look again into the MIPI panel issue.
The PWM backlight output is actively driven to low by the panel. This means that I have backlight voltage if I program the OMAP5 with a pull-up and have no panel connected. If I connect the panel, the signal is 0V actively turning off the backlight. This can only be driven by the panel.
So the question is as simple: which knobs turn on the backlight?
To simplify further experiments I have added a /sys interface to the R63311 driver [1] so that I can send arbitrary commands and read back values.
It works e.g. as this:
echo 51ff >/sys/devices/ocp.3/dss.10/0.dsi/display0/dcs should send 0x51 0xff and turn backlight to full intensity
or
echo 52r >/sys/devices/ocp.3/dss.10/0.dsi/display0/dcs should send a read command 0x52 and read 1 byte back
The interesting thing is that I can really find out that register 52 returns two bytes (0x0000 = backlight permanently off) because 52r and 52rrr fails. But I can't see the value written by the 51 command :(
I just observed by accident that I can *read* the value of register 51 - although that is not described in the data sheet to be possible.
And with that method I found that we can
write 55ff gives read 55r = ff, 56r = 2c
This means that Register 55 and 56 are connected. From register 55 we can read the value that was written to it while register 56 likely masks those bits to 0 that have no function. So it has 3 bits that control something.
For registers 51 and 52 I have basically the same. I can read back the byte value written to 51. But register 52 returns 2 bytes and is always 0000. This obviously corresponds to a turned off black backlight :)
And there are more registers missing in the documentation. E.g. 5e is connected to 5f and has 4 bits.
It turns out to be a real hacking session with the task to jailbreak :)
BR, Nikolaus
And some more good news.
I can read the register 0A (get power mode) and its bit pattern is described in the R61523 datasheet we have.
I read the value 0x1c from our panel - and assuming that it is "standard" that means the display is out of sleep mode, in normal mode and display is on.
And sending the enter_sleep_mode or exit_sleep_mode commands really toggle the SLPOUT bit :)
Unfortunately the R61523 has no integrated backlight controller so I still don't know how to enable it :(
Hm.
Everything I can check and compare with the other data sheets of MIPI-DCS controllers I have does match.
Except two things: 1. I can't modify the backlight intensity value 2. I can't even set the minimum intensity in automatic mode
The ILI9327 chip has an interesting - manufacturer speciflc - command to control the PWM output line and by default it is a steady "0".
So I suspect that we have a similar command in the R63311... But a different one (this one does not work...).
Hm. I only see a chance if we can get the R63311 data sheet through MSC or LG - or find it somewhere on the net.
BR, Nikolaus
http://www.eeesai.com/down_37638.html http://download.csdn.net/download/u011883254/6036925
There appears to be a 4.32MB PDF. But I can't read Chinese... And Google Translate fails.
Do we have someone with Chinese mother language?
BR, Nikolaus
Am Fri, 14 Feb 2014 20:32:52 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Yes, I know some!
I'll ask them, and I'll also try to get the datasheets as well.
BTW: Can you already see a picture? You should be able to see one under a bright lamp if backlight is off.
http://www.eeesai.com/down_37638.html http://download.csdn.net/download/u011883254/6036925
There appears to be a 4.32MB PDF. But I can't read Chinese... And Google Translate fails.
Do we have someone with Chinese mother language?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 14.02.2014 um 21:49 schrieb Michael Mrozek:
Am Fri, 14 Feb 2014 20:32:52 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Yes, I know some!
I'll ask them, and I'll also try to get the datasheets as well.
That would be great help!
BTW: Can you already see a picture? You should be able to see one under a bright lamp if backlight is off.
I have not tried that. But I have just turned on the backlight through a GPIO190. It can be user to "override" the backlight signal coming from the panel.
Yes - there is something - but it is more or less a white oval with rounded corners. And the corners change after a while. And there are some grey stripes.
This looks like a panel right after activating or releasing power (you may know a washing out effect after turning off). And while writing it, the picture became inverted.
It could also be that this panel is broken in the display driver end (I had that swapped +/-5 volts).
So the backlight is not the only issue.
http://www.eeesai.com/down_37638.html http://download.csdn.net/download/u011883254/6036925
There appears to be a 4.32MB PDF. But I can't read Chinese... And Google Translate fails.
Do we have someone with Chinese mother language?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Fri, 14 Feb 2014 21:56:03 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
BTW: Can you already see a picture? You should be able to see one under a bright lamp if backlight is off.
I have not tried that. But I have just turned on the backlight through a GPIO190. It can be user to "override" the backlight signal coming from the panel.
Ah, okay.
Yes - there is something - but it is more or less a white oval with rounded corners. And the corners change after a while. And there are some grey stripes.
Could it be one of the test patterns?
This looks like a panel right after activating or releasing power (you may know a washing out effect after turning off). And while writing it, the picture became inverted.
Hm, well, then it's no test pattern. :)
It could also be that this panel is broken in the display driver end (I had that swapped +/-5 volts).
You have a second one, you could try that.
So the backlight is not the only issue.
But maybe the communication to the Renesas chip is standard, so once you have the datasheet readable, it might be also explain how to properly send picture data.
http://www.eeesai.com/down_37638.html http://download.csdn.net/download/u011883254/6036925
There appears to be a 4.32MB PDF. But I can't read Chinese... And Google Translate fails.
Do we have someone with Chinese mother language?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 15.02.2014 um 01:22 schrieb Michael Mrozek:
Am Fri, 14 Feb 2014 21:56:03 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
BTW: Can you already see a picture? You should be able to see one under a bright lamp if backlight is off.
I have not tried that. But I have just turned on the backlight through a GPIO190. It can be user to "override" the backlight signal coming from the panel.
Ah, okay.
Yes - there is something - but it is more or less a white oval with rounded corners. And the corners change after a while. And there are some grey stripes.
Could it be one of the test patterns?
This looks like a panel right after activating or releasing power (you may know a washing out effect after turning off). And while writing it, the picture became inverted.
Hm, well, then it's no test pattern. :)
Here is a short film showing the blurred edges and issueing the commands 0x10 and 0x11 (enter sleep mode/exit sleep mode).
To me it looks as if the LCD driver is applying some voltage to the LCD backplane but not scanning anything.
(it is still the display #2 and I have not yet tried the other one).
I have now tried the other display + adapter board.
Same washed out image.
So either both panels are damages by wrong +/-5 V or it is a simple but still unknown software/config issue.
BR, Nikolaus
On 02/15/2014 01:40 PM, Dr. H. Nikolaus Schaller wrote:
I have now tried the other display + adapter board.
Same washed out image.
So either both panels are damages by wrong +/-5 V or it is a simple
but still unknown software/config issue.
It could also be the clock rate being out of range, good enough for basic commands but not for synchronizing the image.. Although it might be configuration, pandora's display shows various fading patters if you write bad values through SPI control..
Grazvydas
Am Sat, 15 Feb 2014 17:08:21 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hmmm, so I really need to try to get those details from LG. I'm not sure if only the RS63311 datasheet would help us, as there won't be any documentation about how to program the LCD.
Maybe I'll contact LG directly. What's so hard for MSC to get the info which is needed to get it to work for a display they want to sell to us? They're official German distributor for LG displays...
On 02/15/2014 01:40 PM, Dr. H. Nikolaus Schaller wrote:
I have now tried the other display + adapter board.
Same washed out image.
So either both panels are damages by wrong +/-5 V or it is a simple
but still unknown software/config issue.
It could also be the clock rate being out of range, good enough for basic commands but not for synchronizing the image.. Although it might be configuration, pandora's display shows various fading patters if you write bad values through SPI control..
Grazvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 15.02.2014 um 17:12 schrieb Michael Mrozek:
Am Sat, 15 Feb 2014 17:08:21 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hmmm, so I really need to try to get those details from LG. I'm not sure if only the RS63311 datasheet would help us, as there won't be any documentation about how to program the LCD.
It depends on how much customization is possible. For the other Renesas chip where we have the leaked data sheet it does not look like it has much customization. Except some ID values.
Maybe the main customization is by programming some regulators and gamma curves to match the panel. This appears to be done by the initialization sequence described in the panel data sheet. But there may be another typo like the +/- 5 V thing...
Maybe I'll contact LG directly. What's so hard for MSC to get the info which is needed to get it to work for a display they want to sell to us? They're official German distributor for LG displays...
Yes, that makes me wonder as well. But - it may be easier for them to order something from the LG catalog (and this display is not their standard set of industrial displays) than getting information for a consumer panel. Maybe the information we are looking for is not available that easy within LG themselves? They may not have translated it to English since they usually sell to Asian companies only.
But anyways - if MSC offers it they should have some contacts.
What I though is to contact "Renesas SP Drivers" as well, frankly describe the situation and ask to sign an NDA to get the data sheet. But Renesas is Japanese and they only have a contact bureau in Düsseldorf :(
On 02/15/2014 01:40 PM, Dr. H. Nikolaus Schaller wrote:
I have now tried the other display + adapter board.
Same washed out image.
So either both panels are damages by wrong +/-5 V or it is a simple
but still unknown software/config issue.
It could also be the clock rate being out of range, good enough for basic commands but not for synchronizing the image.. Although it might be configuration, pandora's display shows various fading patters if you write bad values through SPI control..
Grazvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Okay, I did browse the internet a bit.
It seems the LG-D821 uses the LH500WF1-SD02 display, which is (according to Panelook.com) basically the same as the LH500WF1-SD01 with a bit more additional brightness.
But the LH500WF1-SD02 has a more recent datasheet available (v1.3), whereas the latest version of the LH500WF1-SD01 is a preliminary one (v0.1, the one we already have).
I've asked MSC for a datasheet for the LH500WF1-SD02, maybe this has the missing details for us.
BTW: I found the service manual for the LG-D821, but it doesn't say much about the display:
https://doc-0k-0s-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7de...
Am 15.02.2014 um 18:45 schrieb Michael Mrozek:
Okay, I did browse the internet a bit.
It seems the LG-D821 uses the LH500WF1-SD02 display, which is (according to Panelook.com) basically the same as the LH500WF1-SD01 with a bit more additional brightness.
But the LH500WF1-SD02 has a more recent datasheet available (v1.3), whereas the latest version of the LH500WF1-SD01 is a preliminary one (v0.1, the one we already have).
I've asked MSC for a datasheet for the LH500WF1-SD02, maybe this has the missing details for us.
Hm. Interesting because my Panels are LH500WF1-SD02_Ver0.1 on the connector.
So this means we don't have the correct data sheet! Or they delivered a different panel...
Anyways I think they owe us a better data sheet...
BTW: I found the service manual for the LG-D821, but it doesn't say much about the display:
https://doc-0k-0s-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7de...
Yes I have that (I am not sure if I did share the link). The only information we can draw from the schematics is that it really drives by a MIPI interface and not LVDS.
This is why I tried to find the original kernel for this device, but without success so far.
BR, Nikolaus
Am Sat, 15 Feb 2014 18:51:29 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
But the LH500WF1-SD02 has a more recent datasheet available (v1.3), whereas the latest version of the LH500WF1-SD01 is a preliminary one (v0.1, the one we already have). I've asked MSC for a datasheet for the LH500WF1-SD02, maybe this has the missing details for us.
Hm. Interesting because my Panels are LH500WF1-SD02_Ver0.1 on the connector. So this means we don't have the correct data sheet! Or they delivered a different panel...
Oh - I didn't check that!
Well, LH500-WF1-SD02 is probably the current model of the LH500-WF1 series, so maybe 100% compatible.
Anyways I think they owe us a better data sheet...
The v1.3 was on English panelook, which means it's in English and therefore available to us!
Am 15.02.2014 um 18:55 schrieb Michael Mrozek:
Am Sat, 15 Feb 2014 18:51:29 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
But the LH500WF1-SD02 has a more recent datasheet available (v1.3), whereas the latest version of the LH500WF1-SD01 is a preliminary one (v0.1, the one we already have). I've asked MSC for a datasheet for the LH500WF1-SD02, maybe this has the missing details for us.
Hm. Interesting because my Panels are LH500WF1-SD02_Ver0.1 on the connector. So this means we don't have the correct data sheet! Or they delivered a different panel...
Oh - I didn't check that!
Well, LH500-WF1-SD02 is probably the current model of the LH500-WF1 series, so maybe 100% compatible.
Anyways I think they owe us a better data sheet...
The v1.3 was on English panelook, which means it's in English and therefore available to us!
Well, I am not sure how we can download datasheets from Panelook. If there is some simple way we should try it there circumventing MSC and LG.
Maybe it is easier for MSC to say: " we want Version 1.3 of LH500WF1-SD02 because we know for sure that it exists..." :)
BR, Nikolaus
Just a sidenote: today I received the handfull of TPS65133 DC/DC chips. So we can build enough display adapter samples :)
Am Sat, 15 Feb 2014 19:00:30 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Well, LH500-WF1-SD02 is probably the current model of the LH500-WF1 series, so maybe 100% compatible.
Anyways I think they owe us a better data sheet...
The v1.3 was on English panelook, which means it's in English and therefore available to us!
Well, I am not sure how we can download datasheets from Panelook. If there is some simple way we should try it there circumventing MSC and LG.
Either with uploading new datasheets that don't exists to get P-Points (I don't have any) or by paying at least 800 USD per year ;)
Maybe it is easier for MSC to say: " we want Version 1.3 of LH500WF1-SD02 because we know for sure that it exists..." :)
Yep, that's why I sent them an eMail half an hour ago :)
Am 15.02.2014 um 19:23 schrieb Michael Mrozek:
Am Sat, 15 Feb 2014 19:00:30 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Well, LH500-WF1-SD02 is probably the current model of the LH500-WF1 series, so maybe 100% compatible.
Anyways I think they owe us a better data sheet...
The v1.3 was on English panelook, which means it's in English and therefore available to us!
Well, I am not sure how we can download datasheets from Panelook. If there is some simple way we should try it there circumventing MSC and LG.
Either with uploading new datasheets that don't exists to get P-Points (I don't have any) or by paying at least 800 USD per year ;)
Yes, I remember that it isn't easy. Well, I only have one data sheet of the years old and obsolete GTA0x panel - and that may not give sufficient P-Points...
Maybe it is easier for MSC to say: " we want Version 1.3 of LH500WF1-SD02 because we know for sure that it exists..." :)
Yep, that's why I sent them an eMail half an hour ago :)
So we must wait for it :( But as soon as we have it, it should be a matter of 30 minutes to check it and make any modifications we see.
If it still does not work, I have also a plan B2 (B1 is contacting Renesas):
there is one MIPI member on the membership list in Germany. It is a buy-out from HP-Agilent and they make testers for USB, LVDS, MIPI etc. So they must have the right equipment and access to all MIPI documents.
I have two or three potential contacts through which we can try to get in contact with this company and ask for help.
But we should only do that if we completely fail with direct MSC/LG information.
Well, Plan C could be to become member of MIPI and contact Renesas and LG through MIPI. Most likely we would get every bit of required information through this path. Maybe we also need to learn to play Golf first :)
BR, Nikolaus
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
various funny things happened (as usual ;))
Palmer Luckey (the guy behind the Oculus Rift) asked me yesterday what our status with the LCD is - as they're working on low-persistence display technology, which he thinks might be interesting for the Pyra as well (it seems they would be able to simulate CRT-like refresh times).
AFAIK, he also worked together with LG Displays, so I asked him whether he's got a good contact for me. (Will probably take time to get an answer, he usually is busy as hell as well ;))
Then I had the meeting with the keymat company from Munich. They can easily offer transparent silicon keymats with some flat topping, so exactly what we need.
I'll keep you updated about that.
Additionally, they mentioned that in case we're looking for LCDs, they are specialized in that area as well (and also offer LG Displays).
So I'll not try to get more information about the LCD from them as well.
Hi,
okay, I got the information about possible battery size increasements.
The current Pandora battery is 5.75mm * 45mm * 135mm and has 4000mAh (officially)
These sizes are possible:
6.2mm * 49mm * 135MM 5000mAh 7.2mm * 49mm * 135mm 6000mAh
I think I'll get a sample of the 6000mAH one.
4mm increase in width shouldn't be a problem (without having to increase the case). Right now, we're padding the battery compartment of the Pandora to make the battery fit, so the compartment is 1 - 2mm too wide already.
And 1,2mm in thickness could also be brought down to 0,5mm in reality (plastic thickness, etc.)
This sounds like a good idea to me.
And even Pandora users might be able to use the battery, by filing down their battery compartment a bit.
So it's for Pyra or Pandora hackers.
Pandora batteries could still be used in the Pyra if we offer a simple frame to put the battery into.
What do you think?
Am 18.02.2014 um 15:21 schrieb Michael Mrozek:
Hi,
okay, I got the information about possible battery size increasements.
The current Pandora battery is 5.75mm * 45mm * 135mm and has 4000mAh (officially)
These sizes are possible:
6.2mm * 49mm * 135MM 5000mAh 7.2mm * 49mm * 135mm 6000mAh
I think I'll get a sample of the 6000mAH one.
4mm increase in width shouldn't be a problem (without having to increase the case). Right now, we're padding the battery compartment of the Pandora to make the battery fit, so the compartment is 1 - 2mm too wide already.
Ok, if we already have unused space in the battery bay it is no problem. Extending the bay a little could work - but it is already squeezed between the headset jack... Making it 4mm longer is certainly no problem since I already measure 137mm
And 1,2mm in thickness could also be brought down to 0,5mm in reality (plastic thickness, etc.)
Mainly it depends on how precise the battery is packed. The OpenPandora batteries appear to have some tolerances and therefore need a bigger compartment.
But I am not sure if there is 1.2mm excess room. And we might need that for the CPU...
This sounds like a good idea to me.
And even Pandora users might be able to use the battery, by filing down their battery compartment a bit.
So it's for Pyra or Pandora hackers.
Pandora batteries could still be used in the Pyra if we offer a simple frame to put the battery into.
What do you think?
We have to make sure one thing: the battery contacts must be at the right position.
But generally it looks better to me than expected. 6000mAh * 3.7 V = 22 Wh. That is half of my notebook. Wow.
BR, Nikolaus
Am Tue, 18 Feb 2014 16:18:31 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
4mm increase in width shouldn't be a problem (without having to increase the case). Right now, we're padding the battery compartment of the Pandora to make the battery fit, so the compartment is 1 - 2mm too wide already.
Ok, if we already have unused space in the battery bay it is no problem. Extending the bay a little could work - but it is already squeezed between the headset jack...
Well, there's also space on the other side (where the antenna is).
Making it 4mm longer is certainly no problem since I already measure 137mm
It's not made longer :)
And 1,2mm in thickness could also be brought down to 0,5mm in reality (plastic thickness, etc.)
Mainly it depends on how precise the battery is packed. The OpenPandora batteries appear to have some tolerances and therefore need a bigger compartment.
It's also possible to combine the battery and the battery lid to save some more space.
But I am not sure if there is 1.2mm excess room. And we might need that for the CPU...
I wasn't speaking of increasing it to the CPU side, but to the outside.
1,2mm is not that much, especially not compared to what we gain. And the LCD lid will be smaller as well, so the overall thickness should be similar.
Pandora batteries could still be used in the Pyra if we offer a simple frame to put the battery into. What do you think?
We have to make sure one thing: the battery contacts must be at the right position.
Well, we can put those contacts wherever we want. Right now I planned to have 2mm on both sides, so that we can increase the battery compartment just a tiny bit on both sides.
But generally it looks better to me than expected. 6000mAh * 3.7 V = 22 Wh. That is half of my notebook. Wow.
Yep, certainly worth it for the OMAP5, in my opinion.
Hi,
On Tue, Feb 18, 2014 at 3:28 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
...
Additionally, they mentioned that in case we're looking for LCDs, they are specialized in that area as well (and also offer LG Displays).
Maybe they can get some lower resolution ones, 1080p resolution is bad for us surely going to cause trouble..
Gražvydas
Am Wed, 19 Feb 2014 13:16:06 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
yes, I've asked for LCDs with 5" 1280x720pixel (or 720x1280) upwards.
Though I don't think they'll have much to offer - Panelook has mostly every existing LCD in their database, and there just doesn't seem to be much there :/
What I'd like to try out as fast as possible (when we get the display to work) is whether the LG LCD also eats different resolutions (like half HD or 1280x720). With that ppi, I doubt you'll really see scaling artifacts with bare eye, so everyone could use the resolution he'd like.
Additionally, they mentioned that in case we're looking for LCDs, they are specialized in that area as well (and also offer LG Displays).
Maybe they can get some lower resolution ones, 1080p resolution is bad for us surely going to cause trouble..
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
And another link found:
http://wenku.baidu.com/view/8df2f291dd88d0d233d46a1b.html
There one can read the DCS command spec online (no PDF download of single pages - unless we make 131 screen shots :)
It is very slow - but there the plublic defined commands should be described. But I think it is still not enough to understand the R63311 because there are the manufacturere specific commands.
BR, Nikolaus
PS: and another LG display with MIPI commands and backlight - but lacking documentation how to use it: http://www.hy-line.de/fileadmin/hy-line/computer/csv/datasheets/CAS_LD070WX4...