Intel Sends in a Final Batch Of DRM Feature Updates Targeting Linux 4.19 (phoronix.com) 49
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.
Good DRM, not bad DRM (Score:5, Informative)
Re: (Score:1)
Thanks. A good summary would have included this information.
Re: Good DRM, not bad DRM (Score:2, Informative)
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.
** BAD DRM : Intel STEALING from you *** (Score:1)
Don't listen to people saying "it's good"
It's BAD DRM (digital restrictions) inside the Linux DRM (direct rendering)
HDCP = Content Protection [wikipedia.org]
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: (Score:2)
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... [github.com]
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
Digital Rights Managemtn
You made a spelling error. The correct version has "Restrictions".
Re: (Score:2)
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: (Score:2)
Respecting freedom is a huge value in this community until suddenly it is not [google.com]. 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 (Score:1, Interesting)
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: (Score:2)
Right, and to make things even more confusing they put the straightjacket logo...
Re: (Score:2)
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!
Clarification (Score:1)
In this context...
DRM = Direct Rendering Manager
DRM != Digital Rights Management
Rename it already (Score:1)
Seriously, people need to see "DRM" as bad in every context. This association serves to confuse.
I wonder how this is newsworthy? (Score:1)
Re: I wonder how this is newsworthy? (Score:1)
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? (Score:1)
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.
Re: (Score:1)
Maybe they can call it GNAA instead.
Graphics Neutral Acceleration Architecture.