Search results

Your eyes don't seem to agree with you (hence the need for glasses). :rolleyes:

I got the impression they had released a tablet based on the tech. But now I can't find anything on it other than press releases or ImasD showing the device themselves. -_-

Well, this is interesting: Note: Spanish dude, so quite broken english. ^_^ In other words they have a module system similar to Pyra. It's developed by ImasD. Their FAQ: http://www.imasdtecnologia.com/clickarm/index.php/en/faq-questions But none of this is shown anywhere in the...

I personally would rather miss out on some games (or wait a bit longer for Linux release) than to have to deal with whatever tricks Microsoft decides to pull off next. Then again I made the jump a long time ago.

So it begins: ç

First one on the comments section: Kinda says it all. :rolleyes: As for the Smach people, they shouldn't be planning a device based on a SoC which doesn't even exist (publicly, that is). I mean, if it was based on a CPU which was readily available they would be able to show a prototype...

Seems like it. Before: After:

Just out of curiosity I decided to build a mini-timeline of Pyra development starting from little over a year ago pulled from ED's twitter: 15 Apr 2014 The MIPI rotation chips from Solomon Systech have arrived. Aren't they cute? Now waiting for the LCDs to test them. 18 Apr 2014 Due to...

Yes. But I think there's a limit on the number of PNDs which can be mounted at the same time (due to limited number of loopback devices I think).

That's why I suggested making a second script to do what you want. Running the PND normally (via menu/desktop) will execute the original script, while the custom script would only run by invoking pnd_run.sh with the right arguments (-e your_script.sh -a arguments). Yes...

Well, I do this when I want to start Audacious from command line (via ssh X11 forwarding): /usr/pandora/scripts/pnd_run.sh -p /media/PANCARDA/pandora/menu/audacious.pnd -e scripts/audacious2_cli.sh The audacious2_cli.sh script is a modified version of the script included with the PND. Seems...

Exactly, too me it sounds like they are promising things without being sure about what's possible or not. Like they are making a "dash for the cash" and once the cash is on their side all the problems can be solved (hmm, that reminds me of someone :rolleyes: ). But as we all know, even a ton...

I think the OP is missing the point of the Pyra (and it's Pandora predecessor). First and foremost is a portable mini-PC/gaming handheld. To achieve that it needs to have good a good core, display, controls, battery, connectivity. All the stuff mentioned above are just extra burden which...

On December 10 update they said: Not anymore. :P EDIT: Seems they explained it in a comment two days ago: But probably forgot updating the kickstarter description until now.

Seems it's not an official Steam Machine: Guess Valve doesn't want to be associated with them. And also that they were touting that it was a Steam Machine without even asking permission from Valve to make that claim. :rolleyes:

Hmm, I see. Couldn't the same idea be applied in command mode driver? The driver ED linked  seems to do just that: r = request_irq(gpio_to_irq(gpio), taal_te_isr, IRQF_TRIGGER_RISING, "taal vsync", dssdev); Then later in taal_te_isr function they do the update. Not sure but it...

Sorry if I'm insisting too much, but did you see my post here: https://boards.openpandora.org/topic/5600351-not-everything-is-as-fast-as-planned/?page=2#comment-410207 Maybe that's not relevant for our case, but from the little I read it seems like it could work. Nikolaus mentioned that...

Well, if running Steam games is all a person wants from a portable mini-computer then Smach Z is a perfect fit. :rolleyes: Pyra is no steam machine (never was meant to be).

I don't know what kind of people are behind Smach Z, but with Pandora and now Pyra we have great people like EvilDragon, Dr. Nikolaus and many excellent developers which is what makes it so great. Also, having an AMD CPU might not be a good thing...

Can the rotator chip be configured to generate the TE (tearing effect) signal on vsync? According to this PDF the OMAP can be configured (3.1.2 CMOS TE line) to send video data when triggered by the TE signal from the panel. If rotator chip can generate that signal then that would fix the issue...