Samsung's Proposal For A Picture Processing API In Linux DRM

[Ardje]

The thing is, is that it changes a kernel infrastructure. And as we have seen, you don't touch it. How many years did it take to have a HDMI-CEC at all in the kernel? Or take something simple: 99.999% of all usb 2 serial devices have GPIO on board. All attempts to have their driver support the GPIO through some ioctl construct has been killed by upstream because GPIO should use the GPIO subsystem. I think it has been 5 years now since Alan Cox wanted to take a stab on a good infra to make it easy.
Even the V4L2 M2M API took a while before it landed.
So if someone ever complains why there is "no complete upstream" support for a specific SoC, this is it. It takes years to land good infrastructure that everybody agrees with. Until then you are stuck with usually a dated kernel that supports all the hardware.

[ElectricPrism]

Wondering the same... I suspect Prism has confused (FOSS's) Direct Rendering Manager and (corporate America's) Despotic Restriction Machinery?

Thank you for drawing out that common misconception. My awareness of kernel layers and things is still lacking so I appreciate the opportunity to learn.

I usually read Phoronix in the morning too when the coffee hasn't kicked in yet so I'm sure I'm only functioning at about half-speed most of the times.

Also, thanks for the ELI5, simple explanations of complex things are so important to keep it simple.

[liam]

Hopefully something similar would be done for audio decoding. Could be useful for audio playback in low-energy modes (like on Android tablets in suspend mode).

http://www.intel.com/content/dam/www...heet-vol-1.pdf - 7.2.1.1

I believe that's what asoc is for. If you look at each kernel's changelog you'll see TONS of asoc changes to the asoc subsystem.
Btw, asoc stands for Alsa SoC, and is an effort to provide a common interface to both the audio soc and to alsa.
It looks like really nasty work even though there aren't a ton of different codecs out there (hence you shouldn't need many drivers to cover the union), and, it goes without saying, these soc don't have something like acpi.

[RussianNeuroMancer]

I believe that's what asoc is for. If you look at each kernel's changelog you'll see TONS of asoc changes to the asoc subsystem.
Btw, asoc stands for Alsa SoC, and is an effort to provide a common interface to both the audio soc and to alsa.
It looks like really nasty work even though there aren't a ton of different codecs out there (hence you shouldn't need many drivers to cover the union), and, it goes without saying, these soc don't have something like acpi.

So "Offload playback" in "aplay -l" is this thing I talking about? How to utilize that?

[timofonic]

I always see Phoronix news lack expalation of certain interesting details! Why do DRM kernel veterans don't see favorable an upstream merge of this picture processing API? Anyone can provide these details for the rest of people?

[liam]

So "Offload playback" in "aplay -l" is this thing I talking about? How to utilize that?

You should take a look at these docs: https://www.kernel.org/doc/Documenta...c/overview.txt

http://www.alsa-project.org/main/index.php/ASoC

These codecs are really designed for pcm output so you'd still have to translate your music from mp3(or whatever) to a pcm format. Additionally these codecs each have certain capabilities that your data will have to match.
Your can find this with aplay --dump-hw-params

[RussianNeuroMancer]

These codecs are really designed for pcm output so you'd still have to translate your music from mp3(or whatever) to a pcm format.play --dump-hw-params

Then this is quite not what I talking about. As you can see in section 7.2.1.1 of this document, cheap and weak hardware (like this tablet) is capable of decoding many popular formats (include formats popular among software freedom fans) at low-power modes. Playback audio in background of idle mode with very little power consumption is something that possible for smartphones and tablets since forewer, including Android-based devices (include tablet I mentioned, but only when it run Windows or Android, but not GNU/Linux). So I assume code is available, but standartisation for exposing such functionality to user space - that what we lack here. Obviously, even when standard API became available, additional changes will be required to get this working for end-user. I pretty sure that current implementation of suspend freeze doesn't allow to left one application (audio player) running. Moreover, such application will need to be written very thoughtfully to consume as less as possible.

Hopefully, now you have better idea of what I talking about

[Hi-Angel]

the "totally unexpected" part was sarcasm.

You shouldn't add the "really" word. Because for one don't know Samsung's code quality, they reading "totally unexpected" and questioning "was it a sarcasm, or not?". Then they goes on to the ", really" word, and thinking "ah, so it isn't." though actually it is.

[starshipeleven]

You shouldn't add the "really" word. Because for one don't know Samsung's code quality, they reading "totally unexpected" and questioning "was it a sarcasm, or not?". Then they goes on to the ", really" word, and thinking "ah, so it isn't." though actually it is.

Note to self: Dropping the use of "really" and ALWAYS adding /sarcasm tag where due.

[TheLexMachine]

This is a good thing since recent GPUs have integrated hardware accelerated image processing into their ASICs and said hardware is currently inaccessible under Linux, so far as I know. Most of the image editing/viewing/either-or-whatever programs on Linux don't seem to have any hardware accelerated functions, while it's the norm for Windows image editing software.