Jayy001 / Jayy001/rmpp-kms-cube

Insight as to why DRM works within debain-chroot

Open
#2 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Perl
Stars
6
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Hello,
I've been diving headfirst into this brick wall for the past week now, and I was wondering as whether or not you could provide some insight into why drawing to the display works within chroot. I've gotten access to `/dev/mem` (recompiling the kernel without the STRICT IO flag) and I have logs of the IOCTLs that xochitl makes to the DRI (Direct Rendering Interface). Removing their "mask" (0x40006400 on the RmPPM) from their IOCTLs to the DRM device reveals that most of their IOCTL type literals begin with 0x80, corresponding to certain devices and headers (if I'm interpreting the type literal correctly) such as `linux/fb.h`. I've also come to understand that there's a series of I2C writes and GPIO setting before the display is enabled, though I'm unsure as to what's handled by their driver and xochitl. KMS cube doesn't work properly on the RmPPM(it just draws glitchy lines), but it actually draws to the screen. Nothing I've done including directly setting I2C registers and GPIO have made my program which uses the DRI has modified the screen at all. Thank you in advance for your time. Your help and this repository is appreciated

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.