1&1 has some pretty fair plans, too. They even allow you to activate SMS and phonecalls for 19ct per message or minute. (Yes, that's expensive, but better than no calling at all like most data plans.)That offer is already pretty cheap, I doubt I could get something cheaper, even with smaller traffic.
Compared to other tariffs:
O2 2 go Flat L: 12,49 EUR. You get 5GB, but only 7,2MBit speed - for 4 EUR per month more
Telekom: Data Comfort S: 13,45 EUR (only first 12 months, 14,95 EUR after that). You get 1GB and 16MBit/s speed.
AldiTalk: Internet Flatrate L: 9,99 EUR. You get 1,5GB/month, don't even know the speed.
So... I guess I'm pretty good here
All blobs are userspace, kernel parts are open (which also need porting but should not be as huge issue as the blobs). I don't remember the details, it's about a year since I've looked at it and situation has probably changed slightly with Debian 8 release anyway.This still needs to be done for current kernels, right? If so, is there any more information you can give that could help others get started on working on this? That is, if you don't plan to do it."Tiny" blob is needed for any 3d to work at all.
WebGL will be a problem, yes...@ Fullscreen-only 3D: What about HTML5 stuff? Not being able to accelerate that would be a shame, imo.
The OMAP5 should have enough CPU grunt to decode and scale in real time at least a 720p H.264 stream in pure software, with no acceleration whatsoever.And my worries were actualy about general hardware acceleration, not only 3D. On my Pandora I can't watch anything that is .mkv (mostly h.264 encoded), not even with HW acceleration. Afaik even 2D is often HW accelerated and without a real working driver, these things can slow down even fast hardware.
...sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.This is a decoding problem, nothing to do with the display driver. It can put the images to the screen fast enough, uncompressing the video is the hard part. There is no hardware acceleration, it is all CPU.
You can forget about Flash. On linux, there's two usable Flash implementations. The ancient, unsupported plugin from Adobe, and the PPAPI plugin integrated with Chrome. Both are x86[-64] only.Flash (Youtube streaming(!) is important to me) is bad on the Pandora, html5 afaik not even really existant, at least not faster than flash (videos).
This has nothing to do with graphics performance. I don't own a Pandora, but the culprit is probably low "disk" random access speed, exacerbated by low RAM.even 2D stuff is so slow, (...) evan an simple desktop menu takes many seconds to load -WTF?!?
Speak for yourself. Wobbly windows are essential .Inability to use 3D windowed is a shame but probably not a huge loss for most people.
If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora....sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.
On the Pandora we have programs like The Tube that does just that and it works great. Adobe has abandoned the ARM platform long ago, what I have played with using the Devboard, HTML5 videos on youtube work fine with brute CPU, but can be choppy at times.If video streaming is too slow in the browser, you can always extract the media URI and stream the video directly in mplayer or whatever, which could be automated with a browser extension. Even better, somebody could write a dedicated Youtube viewer app for Pandora/Pyra.
Fahrstuhl, on 07 Jul 2015 - 7:09 PM, said: @ Fullscreen-only 3D: What about HTML5 stuff? Not being able to accelerate that would be a shame, imo. WebGL will be a problem, yes...
Theory and Practise I guess, plus classic Pandora at 600-800MHz. ^^" It runs "normal" Videos fine, at least in MPlayer2. However, even non HD videos that are somehow have newer codecs (h.264) don't run well. MPlayer plays it but slow and without sound sometimes but VLC only displays garbage. Which is strange beacuse VLC plays basicly everything on my PC, even stone old versions. VLC on the Pandora is, well, not that great.The OMAP5 should have enough CPU grunt to decode and scale in real time at least a 720p H.264 stream in pure software, with no acceleration whatsoever.
We have the old Firefox flash plugin at least, it works but slow. My WiFi is also very bad which is the reason why streaming is no option (it plays OR streams, not both " ) And before I download the Video, I just watch it on my PC, same DSL, same Router but much faster WiFi. Not to mention Flash.I find HTML5 bad for Videos (and my Opera 12 does not even support it on Youtube ), it eats more CPU than Flash, even on my PC it goes easily over 50% CPU time and I have a 2.66Ghz Quad Core CPU! I can't imagine that any Mobile device can handle all the new fancy HTML5 stuff well. Does HTML5 even have some kind of hardware acceleration?You can forget about Flash. On linux, there's two usable Flash implementations. The ancient, unsupported plugin from Adobe, and the PPAPI plugin integrated with Chrome. Both are x86[-64] only.
Which isn't a bad thing, since everybody is moving to HTML5 anyway. As of today, aside from Flash games and porn video sites, there's hardly any Flash-only content on the web.
I have made videos proving the OMAP5 Devboard can power through decoding 720p and 1080p H.264 videos without issues.Theory and Practise I guess, plus classic Pandora at 600-800MHz. ^^" It runs "normal" Videos fine, at least in MPlayer2. However, even non HD videos that are somehow have newer codecs (h.264) don't run well.
General desktop acceleration. Modern UI toolkits use GL(ES) when available to cut on CPU and power usage. Desktop compositing brings a snappier feel and drastically cut CPU use when moving, switching and rearranging windows. During video playback, colorspace conversion, scaling and subtitle blending can be easily offloaded to the GPU.I can't think of any reason to run 3D windowed on the Pyra.
Do you expect those blobs to support X? AFAIRC, TI now concentrates on the embedded and automotive markets, which aren't exactly places where X is useful...Why not? Those processors from TI are new, and we already used SGX blobs from different systems (like the N900) on the pandora as well, haven't we?Still I think it's extremely unlikely anything will come out of that...The more updated blobs we hopefully will get end 2015 / early 2016 should hopefully work with a more recent X, so that the driver should work without hacking.
There's a video overlay available? Wow, now that fixes the problem. At least as long as you don't want subtitles nicely alpha-blended over videonotaz said:If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora.
Desktop compositing on a mobile device?General desktop acceleration. Modern UI toolkits use GL(ES) when available to cut on CPU and power usage. Desktop compositing brings a snappier feel and drastically cut CPU use when moving, switching and rearranging windows. During video playback, colorspace conversion, scaling and subtitle blending can be easily offloaded to the GPU.I can't think of any reason to run 3D windowed on the Pyra.
No, not X support, but at least the fullscreen stuff should be less hacky.Do you expect those blobs to support X? AFAIRC, TI now concentrates on the embedded and automotive markets, which aren't exactly places where X is useful...
What eats battery is compositor performing spiffy animated effects with GL. You can have plain compositing without the frills and it won't eat any more juice than doing it the old fashioned way (in fact, it may save some).Desktop compositing on a mobile device?
That would eat your battery (like on Android, which does everything with GL).
Ah, now that helps. So with time when wayland matures we'll be able to switch to that and have full GLES on the desktop. At least assuming the driver is stable under desktop-type loads (which they probably didn't test against).The last official driver for the OMAP5 had wayland support, but no X support.
I understand that it's not something in the kernel that has to be changed, but I thought that the problem was that the blobs weren't compatible with interfaces in newer kernels.All blobs are userspace, kernel parts are open (which also need porting but should not be as huge issue as the blobs). I don't remember the details, it's about a year since I've looked at it and situation has probably changed slightly with Debian 8 release anyway.
Also, the 2D accelerator can handle color space conversions and scaling (via bltsville)If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora....sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.
So... go Wayland then like any other mobile linux OS that is tied to Android GPU drivers? Eventually we'll get stable X for Wayland, most probably sooner than a stable X driver from TI."Tiny" blob is needed for any 3d to work at all.
For X support there is another large blob that is tied to specific old X version and was dropped completely by TI in "latest" (2013) driver release. That's not surprising as people who tried TI's Ubuntu 12.04 release reported it's extremely unstable, so instead of fixing it they just dropped all support. It's very unlikely we'll ever have 3d working under X.
It's simply false nowadays. Compositing is very efficient and I even turn it on by default on my laptop.It was inefficient when it all started.Desktop compositing on a mobile device? That would eat your battery (like on Android, which does everything with GL).