- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 1346363_en-US
1346363_en-US
1346363_en-US
1346363_en-US
I am using imx8mp evk development board, linux kernel version is linux-imx-5.10.9. using HDMI interface, I found that the default output is 1080p@60, how can I modify the kernel to make the HDMI output 4K.
Uh, thanks.
The crux of the matter is that we are a medical device company, previously the UI was developed in QT, the platform was your imx6 imx7, and now we are using your 8 for our high end product line. All the previous code was based on fb, it would be costly to switch to drm now ............ Never mind, I'll do some more research and see if I can modify that part of your source code to create different numbers of fbx based on the number of monitors plugged in.
Desktop systems don't use fb0 and use drm nodes, even if fb0 is available, we don't recommend it, the mainstream is the drm framework.
I did not move your kernel on the fb0 generation of the source code, now with your bsp inside the exact same, your source code inside the drm framework is to use the last generated a fb0, on this one, regardless of inserting a few screen is also on this one fb
That is to say lvds and hdmi are plugged in the case, although the two resolutions are not the same, but the kernel application buffer is in accordance with the resolution of the lvds, hdmi and lvds display are also used when the buffer, so that led to the hdmi display abnormal now? Then it's hard to figure out ..........
I thought hdmi switched resolutions adaptively.
-->Based on the DRM API you can realize the buffer allocation under different CRTC, but if you write fb0 directly, that's how you get this display mismatch problem. The buffer you allocate in the application layer must be for a certain screen, such as LVDS resolution size buffer, then you write in, the underlying driver just throws this buffer directly into the lcd controller, the driver layer is very stupid not adaptive. You throw in how much resolution buffer, he will be displayed so large.
We are trying to realize dual screen simultaneous display, qt writes image data to fb0, and we want the image data in fb0 to be displayed on 1200*768 lvds and 1920*1080 hdmi at the same time. Do you think this can't be done? Right now the qt side is using a form of eglfs, for simultaneous display it has to be something like eglfs-kms that operates directly on the cardx node generated by the drm to work?
My current lvds screen is 1200*768 and hdmi supports resolutions up to 1920*1080. So you mean that for the lvds and hdmi to display properly, the hdmi resolution also has to be manually set to something like 1200*768 or a similar resolution to work? I thought the hdmi would adaptively switch resolutions, I see from the hdmi monitor settings that the screen display resolution is now 1920*1080, and the image displayed on the hdmi is only a piece in the upper left corner, and the size is similar to the size of the lvds!
It's been measured and can automatically recognize 4K.
lvds and hdmi share the same fb0 node generated by the drm framework
--" Isn't this only one resolution? With your shared fb0, are the LVDS and HDMI screen resolutions the same?
Is there a solution? I also have a problem now, lvds and hdmi share the same fb0 node generated by the same drm framework, after both lvds and hdmi are connected, the size of the image displayed by the hdmi is the same size as the lvds, it doesn't spread over the whole hdmi display, what's going on?
I can see the same thing. I'll give you the solution later.
I burned demo images of L5.10.35_2.0.0 and tried them on 2K and 4K screens, and they still only display 1080p.
Use modetest to check HDMI maxes out at 1920x1080@60 and doesn't have 4k resolution
HMDI display resolution is adaptive, you try L5.10.35_2.0.0 demo images