Use the hotspot properties from cursor planes
> drm/virtio: Use the hotspot properties from cursor planes
> drm: Remove legacy cursor hotspot code
> drm: Introduce DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT
>
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Simon Ser writes:
Hello Simon,
> On Wednesday, November 22nd, 2023 at 13:49, Javier Martinez Canillas
> wrote:
>
>> Any objections to merge the series ?
>
> No objections from me :)
>
Perfect, I'll merge this series then to unblock the mutter MR. Thanks agai
ct link:
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337
The mutter chages are already in good shape and the MR has even be
approved by a mutter developer. Any objections to merge the series ?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Michael Banack writes:
Hello Michael,
> Yes, that patch should be:
>
> Signed-off-by: Michael Banack
>
Great, thanks for the confirmation.
> --Michael Banack
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
firm that
is the correct thing to do for this patch.
The doc itself looks great to me and it clarifies a lot about
cursor hotspots.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
; Not sure which maintainer will pick up the patch, but I think they can
> fix up this typo on their end (assuming no other reviewer asks for v3).
>
> Reviewed-by: Laszlo Ersek
>
It seems this patch was never picked.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
s well. I see that the Valley View 2 / Minnowboard Max
platform pkg (Vlv2TbltDevicePkg) as references to fTPM and a FTPM_ENABLE var to
enable it, but IIUC the fTPM driver is distributed as proprietary binary files:
https://firmware.intel.com/projects/minnowboard-max
> I think TIS+Cancel / dTPM is the best match: the emulated TPM has to
> be implemented in virtual hardware (not just faked within the guest,
> in RAM), so that QEMU can secure the sensitive stuff from guest
> kernel level access.
>
Agreed.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
On 06/29/2017 06:09 PM, Stefan Berger wrote:
> On 06/29/2017 08:39 AM, Javier Martinez Canillas wrote:
[snip]
>>
>>> = TPM backend devices =
>>>
>>> The TPM implementation is split into two parts. The one part is the hardware
>>> interface, such as
s would explain how the logging
Do you mean that in the past Linux exposed the securityfs files with the event
logs for TPM2 chips as well? My understanding is that Linux does the correct
thing now, since as mentioned the TCPA table should only be used for TPM1.2.
There are patches posted to add Linux
table "Start Method" field as specified in "TCG ACPI
Specification Family 1.2 and 2.0 Version 1.2, Revision 8 February 27, 2017"
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-reviepdf
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
On Wed, Jan 11, 2012 at 1:20 PM, Peter Maydell wrote:
> On 11 January 2012 11:53, Javier Martinez Canillas
> wrote:
>> Yes, the IGEPv2 and the Overo are indeed very similar machines so we
>> base the hardware modeling on the Overo.
>>
>> The only differences here
On Wed, Jan 11, 2012 at 12:15 PM, Peter Maydell
wrote:
> On 11 January 2012 08:43, Javier Martinez Canillas
> wrote:
>> Add ISEE IGEPv2 board definition (an OMAP3730 based board).
>>
>> Signed-off-by: Javier Martinez Canillas
>
Hello Peter,
> It's polite
Add ISEE IGEPv2 board definition (an OMAP3730 based board).
Signed-off-by: Javier Martinez Canillas
---
Makefile.target |2 +-
hw/igep.c | 123 +++
2 files changed, 124 insertions(+), 1 deletions(-)
create mode 100644 hw/igep.c
13 matches
Mail list logo