Intel Sends in a Final Batch Of DRM Feature Updates Targeting Linux 4.19 (phoronix.com)

An anonymous reader shares a report: After several big feature pull requests of new "i915" Intel DRM driver features landing in DRM-Next for Linux 4.19, the Intel open-source developers have sent in what they believe to be their last batch of feature changes for queuing this next kernel cycle. Feature activity has dwindled compared to the earlier pull requests, but this latest gathering of patches does include Intel GVT vGPU huge-page support for guests, continued Panel Self Refresh (PSR) fixes/clean-ups, GMBUS improvements for HDCP v2.2 compliance, GEM memory management improvements, and other display code improvements.

Comments

Good DRM, not bad DRM

[fph il quozientatore]

Before you guys get excited, this is DRM=Direct Rendering Manager (Linux's graphic driver infrastructure), and it has nothing to do with Digital Rights Managemtn.

Re:Good DRM, not bad DRM

[Anonymous Coward]

Thanks. A good summary would have included this information.

Re: Good DRM, not bad DRM

[Anonymous Coward]

That is incorrect. The summary lists the features that were added, including support for HDCP v2.2. HDCP is high definition copy protection, which involves encrypting video signals while being sent to external displays. This is a key component of digital rights management systems by making it difficult to capture video signals and record them. That alone indicates that DRM does, indeed, refer to digital rights management in this context.

Re:Good DRM, not bad DRM

[KiloByte]

Digital Rights Managemtn

You made a spelling error. The correct version has "Restrictions".

Re: Good DRM, not bad DRM

[Anonymous Coward]

False.

This is real Digital Rights Management that it baked into the CPUs under the guise of some other bullshit with the same acronym to confuse people.

The CPU will now scan everything that flows through it for potential copyright violations and Intel will report them directly to all the authorities, collecting a finders fee in process. They just needed to get the Linux folks on board, with systemd being a successful phase-1 complete, they are now moving to phase-2.

You know this is the truth, you know it.

Re:Good DRM, not bad DRM

[DRJlaw]

Digital Rights Managemtn

You made a spelling error. The correct version has "Restrictions".

Show us that you own the exclusive naming rights and you might begin to have a point. The fact that Stallman came along in 1997 and created his own backronym does not suffice to create a sole "correct version."

Re: Good DRM, not bad DRM

[nawcom]

what TFA is referring to:

Hi Dave,

This is probably the last pull request for 4.19 from our side.

Please remind about the gvt-fixes vs gvt-next conflict that I mentioned
yesterday on drm-intel-fixes pull request.

Here goes drm-intel-next-2018-07-12:
On GVT there's the addition of vGPU huge page support for guest,
with one BXT fix and gvt dependency handling.

On Display side there's:
- More PSR clean up and fixes (Rodrigo, DK and Tarun)
- GMBUS improvements for HDCP2.2 compliance (Ram)
- Fix strncpy truncation on intel_tv (Dominique)
- Cleanup modesetting on load-error path (Chris)

On GEM side:
- Gem init hw fix (Michal)
- More selftests fixes (Michal, Chris)
- Execlists optimizations (Chris)
- Introduce i915_address_space.mutex (Chris)
- Stolen memory support for Ice Lake (Paulo)
- Unwind HW init after GVT setup failure (Chris)
- Other fixes for gpu parking, gem_suspend, and handcheck reset (Chris)

drm-intel-next-2018-07-09:
Higlights here goes to many PSR fixes and improvements; to the Ice lake work with
power well support and begin of DSI support addition. Also there were many improvements
on execlists and interrupts for minimal latency on command submission; and many fixes
on selftests, mostly caught by our CI.

General driver:
- Clean-up on aux irq (Lucas)
- Mark expected switch fall-through for dealing with static analysis tools (Gustavo)

Gem:
- Different fixes for GuC (Chris, Anusha, Michal)
- Avoid self-relocation BIAS if no relocation (Chris)
- Improve debugging cases in on EINVAL return and vma allocation (Chris)
- Fixes and improvements on context destroying and freeing (Chris)
- Wait for engines to idle before retiring (Chris)
- Many improvements on execlists and interrupts for minimal latency on command submission (Chris)
- Many fixes in selftests, specially on cases highlighted on CI (Chris)
- Other fixes and improvements around GGTT (Chris)
- Prevent background reaping of active objects (Chris)

Display:
- Parallel modeset cleanup to fix driver reset (Chris)
- Get AUX power domain for DP main link (Imre)
- Clean-up on PSR unused func pointers (Rodrigo)
- Many PSR/PSR2 fixes and improvements (DK, Jose, Tarun)
- Add a PSR1 live status (Vathsala)
- Replace old drm_*_{un/reference} with put,get functions (Thomas)
- FBC fixes (Maarten)
- Abstract and document the usage of picking macros (Jani)
- Remove unnecessary check for unsupported modifiers for NV12. (DK)
- Interrupt fixes for display (Ville)
- Clean up on sdvo code (Ville)
- Clean up on current DSI code (Jani)
- Remove support for legacy debugfs crc interface (Maarten)
- Simplify get_encoder_power_domains (Imre)

Icelake:
- MG PLL fixes (Imre)
- Add hw workaround for alpha blending (Vandita)
- Add power well support (Imre)
- Add Interrupt Support (Anusha)
- Start to add support for DSI on Ice Lake (Madhav)

Thanks,
Rodrigo.

The following changes since commit e1cacec9d50d7299893eeab2d895189f3db625da:

    drm/i915: Update DRIVER_DATE to 20180620 (2018-06-20 14:10:48 -0700)

are available in the Git repository at:

    git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-07-12

for you to fetch changes up to f7cf1a1829f9ff776fb5504c9c5ffa0e9d2baf79:

    drm/i915: Update DRIVER_DATE to 20180712 (2018-07-12 23:54:26 -0700)

Well that's the most open source digital rights management I've ever seen. This is very specifically referring to direct rendering manager: https://github.com/torvalds/li...

Re:Good DRM, not bad DRM

[DRJlaw]

Respecting freedom is a huge value in this community until suddenly it is not. So much for consensus-building and letting individuals exercise semantic control of their language. Kill your values to save them.

Re: Good DRM, not bad DRM

[DRJlaw]

GMBUS improvements for HDCP2.2 compliance (Ram)

This is not a desirable feature you fucking retard. Not an improvement.

Show that properly indexed writes to GMBUS are useful only for HDCP compliance and you might begin to have a point. Even then, it is a desirable feature and improvement. The "don't let DRM contaminate Linux" ship sailed and sank long ago. A larger proportion of Linux desktop users consider the inability to display HDCP-flagged media a bug rather than a feature.

Re:Good DRM, not bad DRM

[GuB-42]

Right, and to make things even more confusing they put the straightjacket logo...

Re:Good DRM, not bad DRM

[BitterOak]

Before you guys get excited, this is DRM=Direct Rendering Manager (Linux's graphic driver infrastructure), and it has nothing to do with Digital Rights Managemtn.

Wow! In that case, this could be about the most misleading Slashdot headline ever. And that's really saying something!

Re: Good DRM, not bad DRM

[Antique Geekmeister]

Most of us consider the DRM a bug in the media and in the vendor, not a bug in the required customized drivers. Those customized drivers and supporting the constant arms race between DRM manufacturers and anyone who wishes to unlock the content take system resources and developer time that could be spent far more efficiently elsewhere.

Also, let us be plain that this "in-line" encryption simply delays the release of the decrypted content on a modern bittorrent or streaming service. The field is experiencing what XKCD described as the "$5 wrench" problem: sophisticated technological limitations are overwhelmed with low cost, common place, physical tools. Some hackers simply record video with a camera from their terminal output, others run it through a virtualization host with a screen capture feature enabled. And most home viewers _do not care_ about the high resolution possible if only the DRM were completely broken. They've no need or desire for those features, and they are _delighted_ that the image they found on Bittorrent is without the forced copyright warnings and previews for shows they have no with to see. The illegal downloads are thus often _better_ than the commercial downloads. They're smaller because they don't contain undesired features, languages, and advertisements.

Re: Good DRM, not bad DRM

[DRJlaw]

Most of us consider the DRM a bug in the media and in the vendor, not a bug in the required customized drivers.

Where "us" is some group that is not even a plurality of Linux users. Most of us want a personal computer than can play legally obtained media.

Again, "Show that properly indexed writes to GMBUS are useful only for HDCP compliance and you might begin to have a point. " But you don't. You instead actively oppose any improvement to the technology, as well as improvements to the end user experience, because it conflicts with your personal philosophy. User freedom, but not the freedom to accept DRM.

Clarification

[Anonymous Coward]

In this context...

DRM = Direct Rendering Manager

DRM != Digital Rights Management

Rename it already

[Anonymous Coward]

Seriously, people need to see "DRM" as bad in every context. This association serves to confuse.

I wonder how this is newsworthy?

[ReneR]

Has Michael that good /. contacts to get so many minor patch news reported every other week!?? In other news, FLAC now decodes ~5% faster on my Sgi Octane w/ Linux: https://www.youtube.com/watch?...

Re: I wonder how this is newsworthy?

[bestweasel]

Personally, I think Michael Larabel deserves some kind of award for singlehandedly (?) producing large amounts of valuable content about Linux. No, I don't know him, never met him, just find his site useful.

Re: I wonder how this is newsworthy?

[bestweasel]

I guess that culling from mailing lists on a daily basis, and then "please support me so I can keep this site going" really tore into you.

No, never noticed either of those.

Or you could just subscribe to the mailing lists yourself, and you would have already read the i915 pull request without the nonsense editorial pandering.

Why would I do that? I'm not really interested in i915 pull requests.

** BAD DRM : Intel STEALING from you ***

[Anonymous Coward]

Don't listen to people saying "it's good"

  It's BAD DRM (digital restrictions) inside the Linux DRM (direct rendering)

HDCP = Content Protection
This prevents you from keeping what you paid for. Stealing electricity for its stupid algorithm.
Nothing about DRM is useful to you.

DRM is just a way to prevent you from keeping things so they can be rented to you forever.

DRM is designed to make you pay again and again. That's the only purpose.

BAD INTEL! Shame on you Intel! You disgusting piece of garbage

Re:Direct Rendering Manager in Linux should be ren

[Anonymous Coward]

Maybe they can call it GNAA instead.

Graphics Neutral Acceleration Architecture.