- 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_ja-JP
1346363_ja-JP
1346363_ja-JP
1346363_ja-JP
現在、Linuxカーネルバージョンlinux-imx-5.10.9を搭載したimx8mp evk開発ボードを使用しています。HDMIインターフェースを使用すると、デフォルトの出力が1080p@60pになっていることに気づきました。HDMI出力を4Kにするには、カーネルをどのように修正すればよいでしょうか？
わかりました。ありがとうございます。
問題の核心は、私たちが医療機器メーカーであるということです。以前のユーザーインターフェースはQTで開発しており、プラットフォームはIMX6とIMX7でした。現在、ハイエンド製品ラインではIMX8を使用しています。以前のコードはすべてFB（Framework Builder）ベースでした。今DRMに切り替えると、非常にコストがかかります…。さて、さらに調査して、ソースコードの該当部分を修正し、接続/切断されたディスプレイの数に応じて異なる数のFBXインスタンスを作成できるかどうか確認してみます。
デスクトップシステムではfb0は使用されず、代わりにdrmノードが使用されます。fb0は使用可能ですが、推奨しません。主流のアプローチはdrmフレームワークです。
カーネル内のfb0生成に関するソースコードには触れていません。BSPと全く同じです。ソースコードはDRMフレームワークを使って1つのfb0を生成するだけで、それだけです。接続された画面の数に関係なく、常に同じfbになります。
つまり、LVDSポートとHDMIポートが接続されていて、解像度が異なっているにもかかわらず、カーネルはLVDSの解像度に基づいてバッファを割り当てているのです。HDMIとLVDSは同じバッファをディスプレイに使用しているため、HDMIディスプレイに不具合が発生しているのでしょうか？これは困ったものです…
HDMIなら解像度が自動的に切り替わると思っていました。
-->DRM APIは異なるCRTCでのバッファ割り当てを許可していますが、fb0に直接書き込むと、表示の不一致という問題が発生します。アプリケーション層で割り当てるバッファは、LVDS解像度のバッファなど、特定の画面用です。バッファに書き込むと、基盤となるドライバは単にこのバッファをLCDコントローラに渡すだけで、ドライバ層はバッファの調整を行いません。そのため、解像度に関係なく、バッファの正確なサイズが表示されます。
デュアルスクリーン同時表示を実現したいと考えています。Qtはfb0に画像データを書き込み、fb0内の画像データを1200*768のLVDSと1920*1080のHDMIに同時に表示したいと考えています。これは不可能だと思いますか？現在、QtはEGFLSを使用しています。同時表示を実現するには、DRMによって生成されたcardXノードを直接操作するEGFLS-KMSを使用する必要がありますか？
私のLVDS画面は現在1200*768ですが、HDMIは最大1920*1080の解像度をサポートしています。つまり、LVDSとHDMIの両方を正しく表示するには、HDMIの解像度を手動で1200*768またはそれに近い解像度に設定する必要があるということですか？HDMIは解像度を自動的に切り替えると思っていました。HDMIディスプレイ設定では、現在の画面解像度は1920*1080で、HDMIに表示される画像は左上隅のみで、サイズはLVDSとほぼ同じです。
テスト済みで4Kを自動認識できます。
LVDS と HDMI は、同じ DRM フレームワークによって生成された同じ FB0 ノードを共有します。
解像度は1つしか設定できないのでしょうか？fb0を共有する場合、LVDSとHDMIの画面解像度は同じになりますか？
解決策はありますか？現在、別の問題が発生しています。LVDSとHDMIは、同じDRMフレームワークによって生成された同じFB0ノードを共有しています。LVDSとHDMIの両方を接続すると、HDMIに表示される画像サイズはLVDSと同じになり、HDMIディスプレイ全体を埋め尽くしません。何が起こっているのでしょうか？
私も同じ状況に遭遇しています。後で解決策をお伝えします。
L5.10.35_2.0.0 のデモイメージを書き込み、2K および 4K 画面で試してみましたが、1080p しか表示できません。
Modetest を使用すると、HDMI 出力の最大解像度は 1920x1080@60 であり、4K 解像度はありません。
HDMIディスプレイは適応型解像度を使用します。L5.10.35_2.0.0のデモ画像をお試しください。