Testers for inxi/pinxi redone -C CPU logic... huge internal changes

h2-1 · 02-13-2022, 05:36 PM

That kde is a good sample, thanks. I'm puzzled as to why kwin_wayland is the compositor but it failed to set the WAYLAND_DISPLAY value. I hope gnome and kde aren't doing something clever there. The compositor logic was revised to show 1 or more compositors instead of the old 'the first that is found', just in case that situation arises.

The ports output was a nice touch, luckily fairly early on a guy testing it was running a laptop using an external monitor with his lid closed, which switched off the laptop screen, and he tripped the 'disabled' but 'connected' status, which I hadn't realized was a thing. So 'off:' means it's connected but disabled, for whatever reason, at least, that's how the kernel sees it. Before he came up with that case, it only had the 'active:' and 'empty:' options for ports.

Testing this stuff is hard because for some of the stuff, it has to be connected to hardware, not virtual machines, as you found, for example a virtual machine 'monitor' is virtual, and has no edid, at least not in my tests.

One of the nastier surprises I got during this process was discovering that xorg xrandr would randomly alter the internal monitor port ids, which are stable and consistent in the /sys/class/drm data, but are unstable and random in xorg data, but we did find some patterns, which allow a good guess to be made to map the internal port ID to the xorg monitor id. As usual, on all my test systems, these were the same in both cases, so I had not found that bug until testers exposed it, then I had to create a mapping function to try to map the xorg id to the kernel sys id.

Then there came the further nasty surprise that Xwayland further abstracted the monitor ids, and gave them totally random XWAYLAND[number] ids, which there was no way to reliably map to the /sys monitor ids. Basically, for 1 monitor, it will be right, for 2 monitors, it will be right if and only if the two /sys monitor ids sort to the same result as sorting the XWAYLAND[number] sorts, if not, they will be reversed, to unknown results. > 2 monitors make this worse, and more likely the matches will be wrong. The only hope is that xrandr synthesizes these ids based on an alpha numeric sort of the discovered real monitor ids in /sys, but there's nothing I can do about that beyond probably adding more tests, or dumping the xrandr data in such cases.

So far, fingers crossed, wayland tools do not appear to do this mapping, but I am not optimistic that they won't also end up randomizing these ids when they feel the creative urge to do so. But I hope they don't, otherwise a lot of this logic will just fall apart.

I've upgraded the internal tests for wayland compositors, which will appear in the -S desktop: item, possibly in the wm: item of -Sxx, and in the compositor: item of -G. These were kind of scattered and hard to maintain previously, now it's integrated and easy to maintain, but I may have broken some fringe window manager IDs, but it was worth it I think.

Next step is to take developer human readable weston-info/wayland-info output and turn it into machine usable output, a step that shouldn't be required since this is relatively new software that should have been written to produce clear machine readable output, but they didn't feel that was necessary, sigh... would have taken so little work to do it well and right....

h2-1 · 02-13-2022, 05:43 PM

fourtysixandtwo, re the error not showing in earlier slackware's with old kernels, that's because that logic was only called when the /sys/class/drm/card0-[ID]/edid file was found. I don't believe the 2.4/2.6 kernels had that part of the /sys file system, and it's also possible that very old monitors did not have edid files, so far in my limited testing, very old monitors have not had edid data, but that's a sample of 1 so not much to be concluded. I can look up in older datasets to see id the edid file existed in /sys with content, but generally it doesn't matter to inxi if it is there or not, if it is, and it can be read and is not empty, then the user gets bonus monitor data, in or out of x/display.

fourtysixandtwo · 02-15-2022, 10:55 AM

Quote:

Originally Posted by h2-1

Next step is to take developer human readable weston-info/wayland-info output and turn it into machine usable output, a step that shouldn't be required since this is relatively new software that should have been written to produce clear machine readable output, but they didn't feel that was necessary, sigh... would have taken so little work to do it well and right....

"But..but...it's new and better" I hear that sigh man.

Fresh output from the -30 version. k53e looks fine, but now missing a lot of data from my main desktop (bottom).

#k53e

Code:

# cat k53e-Gazy1.edid-30-gui 
Graphics:
  Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
    vendor: ASUSTeK
    driver: i915
      v: kernel
    ports:
      active: LVDS-1
      empty: DP-1,HDMI-A-1,VGA-1
    bus-ID: 00:02.0
    chip-ID: 8086:0116
    class-ID: 0300
  Device-2: IMC Networks UVC VGA Webcam
    type: USB
    driver: uvcvideo
    bus-ID: 1-1.2:3
    chip-ID: 13d3:5710
    class-ID: 0e02
    serial: <filter>
  Display: wayland
    server: X.org
      v: 1.20.14
      with: Xwayland
        v: 21.1.4
    compositor: kwin_wayland
    driver:
      loaded: modesetting
      unloaded: vesa
      alternate: fbdev
    display-ID: :0
    screens: 1
    Screen-1: 0
      s-res: 1366x768
      s-dpi: 96
      s-size: 361x203mm (14.2x8.0")
      s-diag: 414mm (16.3")
      Monitor-1: XWAYLAND0
        mapped: LVDS-1
        built: 2010
        res: 1366x768
        hz: 60
        dpi: 102
        gamma: 1.2
        size: 340x190mm (13.4x7.5")
        diag: 395mm (15.5")
        ratio: 16/9
        modes: 1366x768
  OpenGL:
    renderer: Mesa DRI Intel HD Graphics 3000 (SNB GT2)
    v: 3.3 Mesa 21.3.5
    compat-v: 3.0
    direct render: Yes

#main

Code:

# cat m-Gazy1.edid-30-gui-root 
Graphics:
  Message: No device data found.
  Display:
    server: X.Org
      v: 1.20.14
    compositor: kwin_x11
    driver:
      loaded: amdgpu,ati
      unloaded: modesetting,vesa
      alternate: fbdev
    display-ID: :0
    screens: 1
    Screen-1: 0
      s-res: 4480x1440
      s-dpi: 96
      s-size: 1185x381mm (46.7x15.0")
      s-diag: 1245mm (49")
      Monitor-1: DVI-I-0
        pos: right
        res: 1920x1200
        hz: 60
        dpi: 94
        size: 519x324mm (20.4x12.8")
        diag: 612mm (24.1")
      Monitor-2: DisplayPort-0
        pos: primary,left
        res: 2560x1440
        hz: 60
        dpi: 109
        size: 597x336mm (23.5x13.2")
        diag: 685mm (27")
  OpenGL:
    renderer: AMD Radeon HD 7900 Series (TAHITI DRM 3.42.0 5.15.19 LLVM 13.0.0)
    v: 4.6 Mesa 21.3.5
    direct render: Yes

h2-1 · 02-15-2022, 01:58 PM

That was a small bug I introduced while trying to 'streamline' some filter rules and functions, cough.. they got streamlined a bit too much, got another report from someone this morning about that failed attempt to be clever on my part, that's now corrected. That would have been a bad one to release in that form.

Moral of the story, don't mess with core cleaners and filters, they are used all over, and some are more dangerous and destructive potentially than others.

The kwin_wayland has xrandr I assume, or xdpyinfo, one of those, that's the only way the 'Screen-1:' line can appear, since that's an X.org concept which Wayland doesn't use.

Someone is bravely trying to resolve the scattered wayland compositor libraries issue, a KDE guy is trying to make a wlroots based compositor, KWinFT, which if it catches on, would leave only Gnome and Enlightenment as the only other large compositor projects outside of wlroots/sway. I doubt he'll be successful in his attempt to replace kwin_wayland (due to organizational inertia and NIH syndrome) but one can always hope. I did also learn that automotive OEMs like weston compositor for some reason, probably because their use case is very limited, so that one is also actually seeing some use in the real world.

Unfortunately this leaves gnome/kde non handled unless they installed weston package for some reason, or if wayland-info, the standalone version of weston-info, gets packaged, there is some murmur that people do actually recognize that having one global tool might be of some utility!! If it took them 10 years to discover that dead obvious thing, I guess we can say better late than never, but that tool was cloned from weston about a year ago and I've seen no activity related to it beyond the initial creation of the repo.

wayland-info 'features' the same machine hostile output as weston-info, so inxi / pinxi is treating them as one or the other can be used for that data collector, but odds are wayland-info / weston-info will change syntax, I'd put very high odds on that happening because with output that clearly raw and dev debugger left in place quality someone must come along and go, hey, this output is not very good, maybe I'll clean it up or change it! At which point the inxi rules will instantly break since they rely on fragile regex which from experience with that type of output I know will break sooner than later.

fourtysixandtwo · 02-15-2022, 11:37 PM

Everything looks good so far with -32.

h2-1 · 02-16-2022, 01:23 AM

Unless something comes up, I think I"m going to call it good. I haven't found any data sources for kwin or mutter/gnome-shell wayland, so those will just be left to work if person has wayland-info or weston-info installed, otherwise it will fall back to the new /sys monitor logic, which is decent overall, particularly if you install Parse::EDID perl module.

I went though the pinxi.1 man page (use sudo pinxi -U --man to install the man page) and fixed some priority things today, making for a new progression with -G, -Gx, -Gxx, -Gxxx, -Ga, plus -b, -bx.. And also updated help menu, things changed a lot in terms of what happens where, I think I got most of the stuff right, made sure -x level matches between various features in -G, might have missed one or two things.

This one is just going to need data going through it, I am hoping I didn't make any more mistakes that lead to actual output errors, but it's hard to test this one properly since each Monitor/gfx card setup will have different results, particularly for EDID.

But the main goal, to finally build out the Wayland support from the initial basic stub it was previously, and to integrate all the logic so that it's one main engine that fires off various components depending if it's Xvesa, X.org, or Wayland, that all seems to be working nicely now.

Wish I could somehow pull in Parse::EDID automatically but that's well out of inxi's program scope, so that one I'll have to leave up to distro packagers, it will be quite obvious when it's been added as a dependency since there will be better quality monitor data overall.

Thanks for checking for, and finding, heh, issues and bugs, always appreciated.

I anticipate, or at least, hope for, some more data and data sources to come along at some point for other wayland compositors that currently have no direct support support yet. I may do one more wlr-randr tweak to try to grab some data from it, monitor model, but they have mixed several items in one random string (vendor, model, and serial number), where it can be missing any one or more or all of those, which makes parsing it somewhat silly since it's going to be super fragile and prone to error. I left it undone since I've been down that road before and don't really want to go down it again, but I will see.

Updating the docs/man/help actually took a long time, and I fixed/changed/tweaked pinxi as I went along to make sure all the things matched. Probably missed one or two, but it's closer now than before.

h2-1 · 02-16-2022, 01:28 AM

Here's the -G levels now, it flows decently from least to most I think, ok anyway. The best improvement, aside from finally having real wayland support, which was probably inxi's #1 internal issue in my mind, not having that, that is, is now instead of requiring -Ga to see the Screen/Monitor stuff, you see it at -Gxx, then it adds data to it progressively until it's complete, and -Ga is more in tune with other -a features where it's more or less just advanced data, not just a trigger to show the full rows in -G.

Code:

pinxi -Gz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] driver: radeon
    v: kernel
  Display: x11 server: X.Org v: 1.20.13 driver: loaded: modesetting
    resolution: 1: 1280x1024~60Hz 2: 1280x1024~60Hz
  OpenGL:
    renderer: AMD CEDAR (DRM 2.50.0 / 5.14.0-18.1-liquorix-amd64 LLVM 12.0.1)
    v: 3.3 Mesa 21.2.6

Code:

pinxi -Gxz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel bus-ID: 0a:00.0
  Display: x11 server: X.Org v: 1.20.13 driver: loaded: modesetting
    resolution: 1: 1280x1024~60Hz 2: 1280x1024~60Hz
  OpenGL:
    renderer: AMD CEDAR (DRM 2.50.0 / 5.14.0-18.1-liquorix-amd64 LLVM 12.0.1)
    v: 3.3 Mesa 21.2.6 direct render: Yes

Code:

pinxi -Gxxz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel pcie: speed: 2.5 GT/s lanes: 16 ports:
    active: DVI-I-1,VGA-1 empty: HDMI-A-1 bus-ID: 0a:00.0 chip-ID: 1002:68f9
  Display: x11 server: X.Org v: 1.20.13 compositor: xfwm driver:
    loaded: modesetting display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 2560x1024 s-dpi: 96
  Monitor-1: DVI-I-1 pos: primary,left model: SyncMaster res: 1280x1024
    dpi: 96 diag: 433mm (17")
  Monitor-2: VGA-1 pos: right model: DELL 1908FP res: 1280x1024 dpi: 86
    diag: 482mm (19")
  OpenGL:
    renderer: AMD CEDAR (DRM 2.50.0 / 5.14.0-18.1-liquorix-amd64 LLVM 12.0.1)
    v: 3.3 Mesa 21.2.6 compat-v: 3.1 direct render: Yes

Code:

pinxi -Gxxxz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel pcie: speed: 2.5 GT/s lanes: 16 ports:
    active: DVI-I-1,VGA-1 empty: HDMI-A-1 bus-ID: 0a:00.0 chip-ID: 1002:68f9
    class-ID: 0300
  Display: x11 server: X.Org v: 1.20.13 compositor: xfwm v: 4.16.1 driver:
    loaded: modesetting display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 2560x1024 s-dpi: 96 s-size: 677x270mm (26.7x10.6")
    s-diag: 729mm (28.7")
  Monitor-1: DVI-I-1 pos: primary,left model: SyncMaster serial: <filter>
    res: 1280x1024 hz: 60 dpi: 96 size: 338x270mm (13.3x10.6")
    diag: 433mm (17") modes: max: 1280x1024 min: 720x400
  Monitor-2: VGA-1 pos: right model: DELL 1908FP serial: <filter>
    res: 1280x1024 hz: 60 dpi: 86 size: 376x301mm (14.8x11.9")
    diag: 482mm (19") modes: max: 1280x1024 min: 720x400
  OpenGL:
    renderer: AMD CEDAR (DRM 2.50.0 / 5.14.0-18.1-liquorix-amd64 LLVM 12.0.1)
    v: 3.3 Mesa 21.2.6 compat-v: 3.1 direct render: Yes

Code:

pinxi -Gaz
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max:
    gen: 2 speed: 5 GT/s ports: active: DVI-I-1,VGA-1 empty: HDMI-A-1
    bus-ID: 0a:00.0 chip-ID: 1002:68f9 class-ID: 0300
  Display: x11 server: X.Org v: 1.20.13 compositor: xfwm v: 4.16.1 driver:
    loaded: modesetting display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 2560x1024 s-dpi: 96 s-size: 677x270mm (26.7x10.6")
    s-diag: 729mm (28.7")
  Monitor-1: DVI-I-1 pos: primary,left model: SyncMaster serial: <filter>
    built: 2004 res: 1280x1024 hz: 60 dpi: 96 gamma: 1.2
    size: 338x270mm (13.3x10.6") diag: 433mm (17") ratio: 5/4 modes:
    max: 1280x1024 min: 720x400
  Monitor-2: VGA-1 pos: right model: DELL 1908FP serial: <filter>
    built: 2008 res: 1280x1024 hz: 60 dpi: 86 gamma: 1.4
    size: 376x301mm (14.8x11.9") diag: 482mm (19") ratio: 5/4 modes:
    max: 1280x1024 min: 720x400
  OpenGL:
    renderer: AMD CEDAR (DRM 2.50.0 / 5.14.0-18.1-liquorix-amd64 LLVM 12.0.1)
    v: 3.3 Mesa 21.2.6 compat-v: 3.1 direct render: Yes

Dominique* · 02-16-2022, 02:15 PM

I have an Intel Q8300, according to Intel this a Yorkfield processor, according to inxi and pinxi it's a Penryn
https://ark.intel.com/content/www/us...3-mhz-fsb.html

Code:

inxi:
Machine:
  Type: Desktop
  System: Compaq-Presario
    product: VN300AA-ABH CQ5250NL
      v: N/A
      serial: <superuser required>
  Chassis: Hewlett-Packard
    type: 3
    serial: <superuser required>
  Mobo: FOXCONN
    model: ETON
      v: 1.0
      serial: <superuser required>
  BIOS: American Megatrends
    v: 5.05
    date: 09/25/2009

CPU:
  Info:
    model: Intel Core2 Quad Q8300
    bits: 64
    type: MCP
    arch: Core Penryn
    family: 6
    model-id: 0x17 (23)
    stepping: 0xA (10)
    microcode: 0xA07
  Topology:
    cpus: 1
      cores: 4
    smt: <unsupported>
    cache:
      L1: 256 KiB
        desc: d-4x32 KiB; i-4x32 KiB
      L2: 4 MiB
        desc: 2x2 MiB
  Speed (MHz):
    avg: 2000
    high: 2002
    min/max: 2003/2499
    scaling:
      driver: acpi-cpufreq
      governor: ondemand
    cores:
      1: 2000
      2: 2000
      3: 2002
      4: 2000
    bogomips: 20000
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3
  Vulnerabilities:
    Type: itlb_multihit
      status: KVM: VMX unsupported
    Type: l1tf
      mitigation: PTE Inversion
    Type: mds
      status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
    Type: meltdown
      mitigation: PTI
    Type: spec_store_bypass
      status: Vulnerable
    Type: spectre_v1
      mitigation: usercopy/swapgs barriers and __user pointer sanitization
    Type: spectre_v2
      mitigation: Full generic retpoline, STIBP: disabled, RSB filling
    Type: srbds
      status: Not affected
    Type: tsx_async_abort
      status: Not affected

pinxi:
Machine:
  Type: Desktop
  System: Compaq-Presario
    product: VN300AA-ABH CQ5250NL
      v: N/A
      serial: <superuser required>
  Chassis: Hewlett-Packard
    type: 3
    serial: <superuser required>
  Mobo: FOXCONN
    model: ETON
      v: 1.0
      serial: <superuser required>
  BIOS: American Megatrends
    v: 5.05
    date: 09/25/2009

CPU:
  Info:
    model: Intel Core2 Quad Q8300
    bits: 64
    type: MCP
    arch: Core Penryn
    family: 6
    model-id: 0x17 (23)
    stepping: 0xA (10)
    microcode: 0xA07
  Topology:
    cpus: 1
      cores: 4
    smt: <unsupported>
    cache:
      L1: 256 KiB
        desc: d-4x32 KiB; i-4x32 KiB
      L2: 4 MiB
        desc: 2x2 MiB
  Speed (MHz):
    avg: 2000
    min/max: 2003/2499
    scaling:
      driver: acpi-cpufreq
      governor: ondemand
    cores:
      1: 2000
      2: 2000
      3: 2000
      4: 2000
    bogomips: 20000
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3
  Vulnerabilities:
    Type: itlb_multihit
      status: KVM: VMX unsupported
    Type: l1tf
      mitigation: PTE Inversion
    Type: mds
      status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
    Type: meltdown
      mitigation: PTI
    Type: spec_store_bypass
      status: Vulnerable
    Type: spectre_v1
      mitigation: usercopy/swapgs barriers and __user pointer sanitization
    Type: spectre_v2
      mitigation: Full generic retpoline, STIBP: disabled, RSB filling
    Type: srbds
      status: Not affected
    Type: tsx_async_abort
      status: Not affected

h2-1 · 02-16-2022, 02:55 PM

Thanks, those Intel Processor family items are loose, and hard to nail down, intel used those more as marketing items than engineering from what I can see, sometimes the same cpu family/model id will refer to 2 different possible architecture marketing names. Even the same stepping sometimes has that issue. cpu-world agrees, and when I searched for yorkfield in it, I found other family 6, model 17h ID'ed as yorkfield, so that's been changed in pinxi now, thanks.

Technically, inxi shouldn't even be reporting these Core sub family names, but Core lasted so long that it's useful to distinguish them by sub family, similar to P6 II and III

The skylake family is by far the worst, those had several architecture names that can only be ID'ed by stepping. It's actually easy to see where Intel's current woes come from when you look at their family/model IDs, for example, while AMD is moving through Family IDs steadily as Zen progresses, Intel refuses to stop using Family 6, which becomes even more surreal when they introduce an entirely new architecture type, Alder Lake, which is obviously an entirely new cpu family, yet they leave it stuck on family 6.

These kinds of little internal glitches to me are like little windows that expose significant issues within the organization, since if it was a company being run by engineers, those errors wouldn't have happened. Apparently with the new shakeups going on there to avoid total failure, engineering is again being put to the fore, but 5 years or so is a long time to try to catch up in the chip fab business...

I'm only aware of 1 ambiguous Zen ID, that was the sequence between Zen and Zen+, there was one intermediate ambiguous family/model/stepping when they switched to the zen+ family, but I believe that was just a small tweak to the design.

rokytnji · 02-16-2022, 05:25 PM

Chromebook with antiX 19 installed.

Code:

harry@biker:~
$ pinxi -MCazy
Machine:
  Type: Desktop System: Google product: Parrot v: 1.0
    serial: <superuser required> Chassis: type: 3 serial: <superuser required>
  Mobo: Google model: Parrot v: 1.0 serial: <superuser required>
    BIOS: coreboot v: 4.0-6588-g4acd8ea-dirty date: 09/04/2014
CPU:
  Info: model: Intel Celeron 1007U bits: 64 type: MCP arch: Ivy Bridge
    family: 6 model-id: 0x3A (58) stepping: 9 microcode: 0x21
  Topology: cpus: 1x cores: 2 smt: <unsupported> cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 2 MiB
    desc: 1x2 MiB
  Speed (MHz): avg: 800 min/max: 800/1500 scaling: driver: intel_pstate
    governor: powersave cores: 1: 800 2: 800 bogomips: 5986
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: Split huge pages
  Type: l1tf
    mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
    IBRS_FW, STIBP: disabled, RSB filling
  Type: tsx_async_abort status: Not affected
harry@biker:~
$ pinxi -zv7
System:
  Kernel: 4.9.212-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 8.3.0
    Desktop: IceWM 2.9.5 vt: 7 dm: SLiM 1.3.6
    Distro: antiX-19.2_x64-full Hannie Schaft 27 March 2020
    base: Debian GNU/Linux 10 (buster)
Machine:
  Type: Desktop System: Google product: Parrot v: 1.0
    serial: <superuser required> Chassis: type: 3 serial: <superuser required>
  Mobo: Google model: Parrot v: 1.0 serial: <superuser required>
    BIOS: coreboot v: 4.0-6588-g4acd8ea-dirty date: 09/04/2014
Battery:
  ID-1: BATX charge: 12.6 Wh (52.1%) condition: 24.2/37.0 Wh (65.5%)
    volts: 14.9 min: 14.8 model: SANYO AL12B32 type: Li-ion serial: <filter>
    status: Discharging
Memory:
  RAM: total: 3.8 GiB used: 1006.8 MiB (25.9%)
  RAM Report:
    permissions: Unable to run dmidecode. Root privileges required.
CPU:
  Info: dual core model: Intel Celeron 1007U bits: 64 type: MCP
    smt: <unsupported> arch: Ivy Bridge rev: 9 cache: L1: 128 KiB L2: 512 KiB
    L3: 2 MiB
  Speed (MHz): avg: 800 min/max: 800/1500 cores: 1: 800 2: 800
    bogomips: 5986
  Flags: acpi aperfmperf apic arat arch_perfmon bts clflush cmov
    constant_tsc cx16 cx8 de ds_cpl dtes64 dtherm dts epb ept erms est
    flexpriority flush_l1d fpu fsgsbase fxsr ht ibpb ibrs kaiser lahf_lm lm
    mca mce md_clear mmx monitor msr mtrr nonstop_tsc nopl nx pae pat pbe
    pcid pclmulqdq pdcm pebs pge pln pni popcnt pse pse36 pts rdtscp rep_good
    sep smep ss ssbd sse sse2 sse4_1 sse4_2 ssse3 stibp syscall tm tm2
    tpr_shadow tsc tsc_deadline_timer vme vmx vnmi vpid x2apic xsave xsaveopt
    xtopology xtpr
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel
    ports: active: LVDS-1 empty: DP-1,HDMI-A-1,VGA-1 bus-ID: 00:02.0
    chip-ID: 8086:0156 class-ID: 0300
  Device-2: Chicony type: USB driver: uvcvideo bus-ID: 1-1.3:4
    chip-ID: 04f2:b336 class-ID: 0e02
  Display: x11 server: X.Org v: 1.20.4 driver: loaded: modesetting
    unloaded: fbdev,vesa display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.2x8.0")
    s-diag: 414mm (16.3")
  Monitor-1: LVDS-1
    model: UV�(PTZP00 6� �AUO
    res: 1366x768 hz: 60 dpi: 136 size: 256x144mm (10.1x5.7") modes: 1366x768
  OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 18.3.6
    compat-v: 3.0 direct render: Yes
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio
    driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20
    class-ID: 0403
  Sound Server-1: ALSA v: k4.9.212-antix.1-amd64-smp running: yes
Network:
  Device-1: Qualcomm Atheros AR9462 Wireless Network Adapter vendor: Foxconn
    driver: ath9k v: kernel bus-ID: 01:00.0 chip-ID: 168c:0034 class-ID: 0280
  IF: wlan0 state: up mac: <filter>
  IP v4: <filter> scope: global broadcast: <filter>
  IP v6: <filter> scope: link
  Device-2: Broadcom Limited NetLink BCM57785 Gigabit Ethernet PCIe
    vendor: Acer Incorporated ALI driver: N/A port: N/A bus-ID: 02:00.0
    chip-ID: 14e4:16b5 class-ID: 0200
  WAN IP: <filter>
Bluetooth:
  Device-1: Foxconn / Hon Hai type: USB driver: btusb v: 0.8 bus-ID: 1-1.1:5
    chip-ID: 0489:e04e class-ID: e001
  Report: hciconfig ID: hci0 rfk-id: 1 state: down bt-service: running
    rfk-block: hardware: no software: yes address: <filter>
Logical:
  Message: No logical block device data found.
RAID:
  Message: No RAID data found.
Drives:
  Local Storage: total: 14.91 GiB used: 8.06 GiB (54.0%)
  ID-1: /dev/sda vendor: SanDisk model: SSD U100 16GB size: 14.91 GiB
    speed: 3.0 Gb/s type: SSD serial: <filter> rev: 6.14 scheme: GPT
  Message: No optical or floppy data found.
Partition:
  ID-1: / size: 14.62 GiB used: 8.06 GiB (55.1%) fs: ext4 dev: /dev/sda1
    label: rootantiX19 uuid: fd5a926f-f3df-452b-84d5-d72ac28c3f8b
Swap:
  Alert: No swap data was found.
Unmounted:
  Message: No unmounted partitions found.
USB:
  Hub-1: 1-0:1 info: Full speed or root hub ports: 3 rev: 2.0 speed: 480 Mb/s
    chip-ID: 1d6b:0002 class-ID: 0900
  Hub-2: 1-1:2 info: Intel Integrated Rate Matching Hub ports: 4 rev: 2.0
    speed: 480 Mb/s chip-ID: 8087:0024 class-ID: 0900
  Device-1: 1-1.1:5 info: Foxconn / Hon Hai type: Bluetooth driver: btusb
    interfaces: 2 rev: 1.1 speed: 12 Mb/s power: 100mA chip-ID: 0489:e04e
    class-ID: e001
  Device-2: 1-1.3:4 info: Chicony type: Video driver: uvcvideo
    interfaces: 2 rev: 2.0 speed: 480 Mb/s power: 500mA chip-ID: 04f2:b336
    class-ID: 0e02
  Hub-3: 2-0:1 info: Full speed or root hub ports: 3 rev: 2.0
    speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900
  Hub-4: 2-1:2 info: Intel Integrated Rate Matching Hub ports: 4 rev: 2.0
    speed: 480 Mb/s chip-ID: 8087:0024 class-ID: 0900
Sensors:
  System Temperatures: cpu: 52.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 180 Uptime: 1h 26m wakeups: 40077 Init: SysVinit v: 2.93
  runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Packages: apt: 1670
  Shell: Bash v: 5.0.3 running-in: roxterm pinxi: 3.3.12-33
harry@biker:~
$

h2-1 · 02-16-2022, 06:16 PM

rokytnji, perfect timing, I literally a few minutes ago removed the fallback attempt to do a string parse of the binary edid file in system:

Code:

model: UV�(PTZP00 6� �AUO

and that's why I decided to remove it, too unreliable. Annoyingly, on all my test monitors i have it gave quite good string output, but apparently mine are not very representative. I could in theory reject such results if they contained non printing characters, like yours, but overall, that data just seems too unreliable, though it's my strong preference to show something as fallback if something usable was found since not many people will install Parse::EDID unless their distros did it in the packaging of inxi.

Now pinxi will only look for advanced monitor data if Parse::EDID or one other fallback which I don't recommend because it's got quite weak output. However,

Basically the Wayland compositor output/display tools do one thing that xrandr doesn't, they show either very complete, or partial, monitor EDID data if it was there. swaymsg does it best of all of them, there is not much difference beyond a few extra fields for positions and scale between swaymsg and Parse::EDID, but that only helps the relatively few users of sway, nobody else.

I am adding a --force edid / --edid flag to force the parsing of the binary which can be useful to test or check a remote system or whatever, but I think it shouldn't be a default fallback action since it's wrong so often.

The new filters I added however would have prevented your corrupt string from showing I believe since it contained non printing characters, which I had forgotten to test against. If all is working as hoped, now:

pinxi -Ga --edid

will show nothing for Monitor model:.

fourtysixandtwo · 02-16-2022, 10:16 PM

h2-1,

I modified an existing slackbuild to make it easier to install/uninstall perl-Parse-EDID on several machines. I thought I'd add it here to save anyone else the trouble. I left the maintainer info blank.

README

Code:

Parse::EDID - Extended display identification data (EDID) parser

This module provides some function to parse Extended Display Identification
Data binary data structures.

perl-Parse-EDID.info

Code:

PRGNAM="perl-Parse-EDID"
VERSION="1.0.7"
HOMEPAGE="https://metacpan.org/pod/Parse::EDID"
DOWNLOAD="https://www.cpan.org/authors/id/G/GR/GROUSSE/Parse-EDID-1.0.7.tar.gz"
MD5SUM="0f213f667293752057d939f7f2d4dc23"
DOWNLOAD_x86_64=""
MD5SUM_x86_64=""
REQUIRES=""
MAINTAINER=""
EMAIL=""

slack-desc

Code:

# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description.
# Line up the first '|' above the ':' following the base package name, and
# the '|' on the right side marks the last column you can put a character in.
# You must make exactly 11 lines for the formatting to be correct.  It's also
# customary to leave one space after the ':' except on otherwise blank lines.

                     |-----handy-ruler------------------------------------------------------|
perl-Parse-RecDescent: Parse::EDID - Extended display identification data (EDID) parser
perl-Parse-RecDescent:
perl-Parse-RecDescent: This module provides some function to parse Extended Display
perl-Parse-RecDescent: Identification Data binary data structures.
perl-Parse-RecDescent:
perl-Parse-RecDescent: Homepage:
perl-Parse-RecDescent: https://metacpan.org/release/GROUSSE/Parse-EDID-1.0.7
perl-Parse-RecDescent:
perl-Parse-RecDescent:
perl-Parse-RecDescent:
perl-Parse-RecDescent:

perl-Parse-EDID.SlackBuild

Code:

#!/bin/bash

# Slackware build script for perl-Parse-EDID

# Copyright <year> <you> <where you live>
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

cd $(dirname $0) ; CWD=$(pwd)

PRGNAM=perl-Parse-EDID
VERSION=${VERSION:-1.0.7}
BUILD=${BUILD:-1}
TAG=${TAG:-_custom}
PKGTYPE=${PKGTYPE:-tgz}

SRC_PRGNAM=Parse-EDID

if [ -z "$ARCH" ]; then
  case "$( uname -m )" in
    i?86) ARCH=i586 ;;
    arm*) ARCH=arm ;;
       *) ARCH=$( uname -m ) ;;
  esac
fi

# If the variable PRINT_PACKAGE_NAME is set, then this script will report what
# the name of the created package would be, and then exit. This information
# could be useful to other scripts.
if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
  echo "$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE"
  exit 0
fi

TMP=${TMP:-/tmp/SBo}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}

DOCS="Changes README"

if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
fi

set -e

rm -rf $PKG
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
rm -rf $SRC_PRGNAM-$VERSION
tar xvf $CWD/$SRC_PRGNAM-$VERSION.tar.gz
cd $SRC_PRGNAM-$VERSION
chown -R root:root .
find -L . \
 \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 -o -perm 511 \) \
 -exec chmod 755 {} \; -o \
 \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
 -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;

perl Makefile.PL INSTALLDIRS=vendor
make
make test
make install DESTDIR=$PKG

mv $PKG/usr/share/man $PKG/usr/

( cd $PKG/usr/man
  find . -type f -exec gzip -9 {} \;
  for i in $( find . -type l ) ; do ln -s $( readlink $i ).gz $i.gz ; rm $i ; done
)

( cd $PKG
  find . -name perllocal.pod -o -name ".packlist" -o -name "*.bs" | xargs rm -f
  find . -depth -type d -empty -delete
)

mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
cp -a $DOCS $PKG/usr/doc/$PRGNAM-$VERSION
cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild

mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

cd $PKG
/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE

h2-1 · 02-16-2022, 10:58 PM

Interesting, I hadn't looked at the Parse::EDID code before, it's 650 lines. Just a bit long to put into pinxi, but in theory, I could, it would just be another biggish class/package.

The slackpkg build looks nice, easier to understand than the tce package stuff I try to figure out for TinyCore tce packaging.

It's tempting to just pop that code in, it's even GPL 3 so it would be fine to use it. Only thing it is has raw data in it, and if that gets updated, I'd have to track it, which would be a pain, though not hard.

I may do a test build of this just to see how it works, if it's easy or not.

h2-1 · 02-16-2022, 11:11 PM

Tested this, and it 'just worked', not a single glitch or bug, now, is 650 lines of code worth it?

This is running in pinxi now, and it's identical, being the same code, it would have to be, but you never know.

I've never directly imported any code before, but I've also never required a Perl Module for standard user actions and output options, just for debugging and data export to xml, json turned out they have a core modules JSON::PP so really there's nothing normal anyone would do not covered by Core Modules.

Hmmmm..... if I leave this included, then monitors will work for almost all linux + edid containing monitors, and Wayland will have out of the box almost full monitor data, except for position, scaling, and a few other things, but not many. Including it in the code is faster than importing an external perl module... hmmm...

h2-1 · 02-17-2022, 01:24 PM

The advantages with simply integrating this Parse::EDID code base simply outweigh the disadvantages, the main one being about 500 extra lines of code (after removing everything not needed anymore if no fallbacks were needed), and having to watch the Parse::EDID package for changes, but its changelog indicates virtually no activity, last major work done on it was 2018, and the previous work done was in 2012-13, for the original module creation, and some updates for distros etc, and it's easy to import the code, takes just a minute or two, a few more if I want to remove many empty lines from the code, but essentially no time.

Reading the EDID blob takes roughly 0.001 seconds, give or take, between 0.0008 and 0.0012 or so on my system, it's essentially instant, and supplies almost all the data that the various tools like randr, wlr-randr, swaymsg, weston-info, supply in terms of the monitor data itself, though those also mix in wayland or xorg data about the display size and resolution etc.

While adding 500 lines like this makes me wince a bit, the advantages seem to overcome the disadvantages, first, it's inxi policy, my policy, that is, to never require any module not in perl core modules, and Parse::EDID isn't in core modules, also, it's not in every distro as a package even. Second, in terms of inxi execution time, adding in 500 lines or so makes very little difference, and is certainly significantly faster than having to stop to check and import an external perl module.

The module contains as far as I can tell only a few data structures that will be updated now and then, with different monitor size and configurations, but it's easy to grab those from the cpan source if that is updated ever. I'll contact the module maintainer and let him know it will come into probably wider use than he's used to, but that I also won't change anything in it to make bug and issue handling possible.

With this logic, I can almost, but not quite, dump the various tools inxi uses for graphics, it's too bad in a sense that all I need them for now roughly is the X.org 'Screen' data, or Wayland Display (the respective 'containers' for the monitors, or as wayland calls them, 'outputs', and the monitor positions, and status as primary or not, in that screen, if > 1 monitor, but there's no way to get that data from EDID since that's strictly per monitor. Also, for BSD, they don't have anything like /sys file system, which conveniently exposes the raw edid binary for use, so unless they can come up with something very similar to /sys/class/drm data files, BSD will be out of luck in this case, and will have to fallback to the tools, which themselves seem to contain basic EDID parsing logic already since otherwise things like xrandr wouldn't know the mm dimensions of the monitor. You can tell this is the case because in vm, which do not have edid data, the monitor size data is 0x0mm, and no model names etc are found.

There is one field however in ParseEDID that could be improved, they return a 3 letter vendor ID, but that's only useful if you have a corresponding matching table, which I think wlr-randr has, that would be useful to grab, since otherwise I can't use the vendor ID, which is I believe quite definitive.