On Tue, 7 Oct 2025, Thomas Zimmermann wrote:
> Hi > > Am 03.10.25 um 21:50 schrieb Helge Deller: > > On 10/3/25 20:43, sukrut heroorkar wrote: > > > On Thu, Oct 2, 2025 at 8:52 AM Thomas Zimmermann <[email protected]> > > > wrote: > > > > Am 02.10.25 um 08:41 schrieb Helge Deller: > > > > > > > > kernel test robot noticed the following build errors: > > > > > > > > > > > > > > Did you compile and test this code before submitting this patch? > > > > > > > > > > > > Yes, I had compiled & loaded the udlfb module with no errors. Please > > > > > > let me know how to proceed in this case. > > > > > > > > > > Look at the reported build error, which seems to happen in dev_dbg(). > > > > > So, maybe in your testing you did not have debugging enabled? > > > > > The report contains the .config file with which you can test. > > > > > > > > Can we rather make an effort to remove the udlfb driver entirely? A few > > > > years back, there was one user who was still using it because of some > > > > problems with the DRM udl driver. But I think we've addressed them. The > > > > discussion is at [1]. It was me - and I am still using it on an ARM64 MacchiatoBIN board because the board doesn't have graphics output. The problems with the UDL DRM driver were: * crashes with full-screen framebuffer applications, such as "links2 -g", "fbi" or "fbgs". On UDLFB, there are no crashes. * worse performance - the UDL DRM driver updates everything in a given rectangle, while the UDLFB driver keeps back-buffer and front-buffer and updates only differences between them. * crash when you unplug the card while Xorg was running (already fixed) Mikulas
