From: nospam@needed.invalid   
      
   On Sat, 9/27/2025 8:00 AM, pinnerite wrote:   
   > On Fri, 26 Sep 2025 18:14:23 -0400   
   > Paul  wrote:   
   >   
   >> On Fri, 9/26/2025 5:59 PM, Paul wrote:   
   >>   
   >>>   
   >>> If the monitors are really there, an XRandR command should be able   
   >>> to make the monitors do things.   
   >>>   
   >>> But first the monitors have to be list-able, as HDMI-1 and HDMI-2   
   >>> or whatever.   
   >>>   
   >>>    https://wiki.archlinux.org/title/Xrandr   
   >>   
   >> And Wayland would be a different matter. (Pure Wayland needs a different   
   tool.)   
   >>   
   >> But you could be using an X11 server via XWayland compatibility interface   
   on Wayland.   
   >>   
   >> System:   
   >>   Host: CHARGER Kernel: 6.8.0-84-generic arch: x86_64 bits: 64   
   >>   Desktop: MATE v: 1.26.2 Distro: Linux Mint 22.2 Zara   
   >>   
   >> Graphics:   
   >>   Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.20.0.0   
   >>   Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:   
   >>     loaded: vmware unloaded: fbdev,modesetting,vesa dri: swrast gpu: vmwgfx   
   >>     resolution: 1440x900~60Hz   
   >>   
   >> bullwinkle@CHARGER:~$ xrandr --listmonitors   
   >> Monitors: 1   
   >>  0: +*Virtual1 1440/381x900/238+0+0  Virtual1   
   >>   
   >>    Paul   
   >>   
   >>   
   >  xrandr --listmonitors only lists one monitor.   
   >   
   > Alan   
   >   
      
   There is a driver not loaded in this report (due to Secure Boot or something).   
   But the None-1 mapping is the breadcrumb. Some aspect of the driver is   
   not working properly. The trick then, is to get your AI to recognize   
   the pattern of brokenness, in the detailed INXI output :-)   
      
   https://forums.linuxmint.com/viewtopic.php?t=443254   
      
     LANG=C inxi -Fxxxrzc0 --usb       # More details   
      
     Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:   
       loaded: amdgpu,modesetting,nouveau unloaded: fbdev,vesa dri: swrast   
       gpu: amdgpu display-ID: :0 screens: 1   
     Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")   
       s-diag: 582mm (22.93")   
     Monitor-1: Unknown-1 mapped: None-1 res: 1920x1080 hz: 60 size: N/A   
       modes: 1920x1080   
      
   *******   
      
   There are two kinds of video cards, VESA and GOP. VESA is how we started   
   graphics, a simpler time. When UEFI came along, a new standard for video card   
   interfacing came with it, which was GOP. For a while, cards came still   
   with VESA VBIOS (and a flash file was provided for GOP), while some   
   other cards had GOP+VESA VBIOS. Then later, the video cards got GOP-only   
   VBIOS. This means there is a "disconnect" when sticking newer cards, in   
   much older PCs. I think I had one case here, of plugging a new/old mix   
   together and I couldn't get graphics to work at all (had to put old card back).   
   The card was a GOP-only, the motherboard was a legacy BIOS.   
      
   Now, once you've got the GOP card, if Secure Boot is enabled, then there   
   are yet more details for getting it to work. You would think the NVidia   
   Binary Blob would be signed and would not cause a problem. There are two   
   possible Microsoft certificates in the MOK (as left behind by a windows 11   
   install maybe). Linux covered this at the OS signing level, with shims   
   signed with the newer certificate (when the older certificate gets revoked).   
      
   These two paragraphs are just to give some idea, a "flavour", of the   
   ruination under our machines. The hurdles to make things work. Occasionally,   
   one of those edge cases bites. But, perhaps, somewhere in your inxi,   
   a pattern can be detected, of mischief.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)