Hello:

My newly upgraded Daedalus installation loads a couple of modules I don't need:

~$ sudo dmesg
--- snip ---
[   26.714355] lp: driver loaded but no devices found
[   26.722412] ppdev: user-space parallel port driver
--- snip ---

~$ lsmod | grep "lp\|parport\|pdev"  
parport_pc             40960  0
ppdev                  24576  0
lp                     20480  0
parport                73728  3 parport_pc,lp,ppdev
--- snip ---

My Samsung M2020W printer is USB and uses the usbcore module:

~$ sudo dmesg
--- snip ---
[   24.245461] usblp 6-5:1.0: usblp1: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04E8 pid 0x3321
[   24.245834] usbcore: registered new interface driver usblp
~$
--- snip ---

Although I do have an onboard serial 8250/16550 port in my box (which I use every so often), there is no on-board parallel port in the mb.
So it seems a good idea to avoid loading it at boot time.

It seems there are two posible ways to do this:
One would be the parport=0 kernel command line, which I expect nip the whole process in-the-bud or alternatively, blacklisting the module.

Am I correct in assuming that the kernel command line option is the most efficient way?

Thanks in advance.

Best,

A.

Hello:

Asked apt to update early today:

~$ sudo apt update
Hit:1 http://deb.devuan.org/merged daedalus InRelease
Hit:2 http://deb.devuan.org/merged daedalus-updates InRelease
Hit:3 http://deb.devuan.org/merged daedalus-security InRelease
Reading package lists... Done                     
Building dependency tree... Done
Reading state information... Done
89 packages can be upgraded. Run 'apt list --upgradable' to see them.
~$ 

89 packages seemed rather a large number so I checked my /etc/apt/sources.list and asked again, with the same result.

--- snip ---
89 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 236 MB of archives.
After this operation, 470 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

The three new packages are linux-headers-6.1.0-22-amd64, linux-headers-6.1.0-22-common and linux-image-6.1.0-22-amd64.

Watching the printout as it rolled on, I noticed multiple lines which started with a W:

--- snip ---
update-initramfs: Generating /boot/initrd.img-6.1.0-22-amd64
W: Possible missing firmware /lib/firmware/nvidia/gp100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp100/acr/bl.bin for module nouveau
--- snip ---
W: Possible missing firmware /lib/firmware/nvidia/tu102/sec2/image.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/tu102/sec2/desc.bin for module nouveau
--- snip ---

It was a very long list of Possible missing firmware entries which I have shortened for clarity.
Everything else went on as expected and sudo apt install -f had nothing to say.

Anyone else see this?
Have not rebooted yet so I cannot say if there are any ill effects.
I will check the logs report later.

Thanks in advance.

Best,

A.

Hello:

Still trying to solve a relatively small but annoying tear/artifact in my xorg/nouveau setup in Dadedalus.

Like I posted here:

I have managed to sort out an xorg.conf with just a Monitors section to exactly duplicate what xorg automagically does by itself without one for a three 19" monitor setup with two Nvidia FX580 cards and no Xinerama.

Not using Xinerama is a large bonus: now RandR can be used and other applicatons (such as Firefox) which use its output don't make a mess of the way the drop down menus work. ie: invading the next monitor's screen when deploying sideways.

~$ cat /etc/X11/xorg.conf
# xorg.test - started 20240618
# Layout for four screens - 4th. screen not connected
#
#     (0,0)---------+(1280,0)------+(2560,0)------+
# 1 > |             ||             ||             |(3840,256)---+
# 0 > |  1280x1024  ||  1280x1024  ||  1280x1024  ||  1024x768  |< 7
# 2 > |     DP-3    ||    DP-1-2   ||     DP-4    ||   DP-1-1   |< 6
# 4 > |    SM940n   ||    D1914S   ||    SM940n   ||   P150S    |< 8
#     +-------------++-------------++-------------++------------+
#     |<--- 1280 ---|
#     |<---------  2560  --------->|
#     |<-----------------  3840  ---------------->|
#     |<------------------------  4864  ----------------------->|
#

### <--- MONITORS ###                           
Section "Monitor"
    Identifier  "DP-3"
#   Option      "Primary" "true"                   # defined in Option "Position"
    Option      "DPMS" "0"
    Option      "PreferredMode" "1280x1024_75.00"
    Option      "Position" "0 0"
 EndSection

Section "Monitor"
    Identifier  "DP-1-2"
#   Option      "LeftOf" "DP-4"                    # defined in Option "Position"
    Option      "DPMS" "0"
    Option      "PreferredMode" "1280x1024_75.00"
    Option      "Position" "1280 0"
EndSection

Section "Monitor"
    Identifier  "DP-4"
#   Option      "RightOf" "DP-1-2"                 # defined in Option "Position"
    Option      "DPMS" "0"
    Option      "PreferredMode" "1280x1024_75.00"
    Option      "Position" "2560 0"
EndSection
 
#####################################################################################
# Section "Monitor"                                # not connected 
#   Identifier  "DP-4"                             # n/c check with monitor connected
#   Option      "RightOf" "DP-1-2"                 # defined in Option "Position"
#   Option      "DPMS" "0"
#   Option      "PreferredMode" "1024x768"
#   Option      "Position" "3840 256"              # n/c check with monitor connected
# EndSection
######################################################################################

### MONITORS --> ###

This makes for a 3840x1024 screen, which xrandr IDs as Screen0:

~$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1024, maximum 8192 x 8192
DVI-I-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm

Unfortunately, I have not been able to find out what settings I need for the ServerLayout, Device and Screen sections to be able to finish putting together a complete xorg.conf which I hope to be able to tweak so as to get the most of my twin card setup.   

But I think I have found the origin of the diagonal tear at times present in the middle of my center monitor's screen (upper left down to lower right).

While trawling the web I came across this tidbit:

Did not quite understand what it was about till I realised that I don't have three working 1280x1024 screens but one 3840x1024 screen driven by the combined output from the two cards, each card driving 50% of the whole screen.

And the display boundary mentioned in the cited post being the slight diagonal tear I see in the center of the 3840x1024 screen.

This is as far as I have been able to get.

Any ideas on how to continue?
I think there is room for improvement as I expect that whatever settings the xorg/nouveau combo is using are probably default/conservative.

Thanks in advance.

Best,

A.

Hello:

After quite a bit of hassle, I was able to get CUPS working properly in my upgraded Daedalus installation.
It was working perfectly well in Beowulf but something happened on the way to Daedalus, so to speak and eventually had to resort to a complete purge of anything and everything CUPS related to then reinstall the application.

Doing things 'the Windows way' is not my idea of fixing things like these in a proper manner, but I was at my wits' end.

I have no idea why all this happened but now it seems to work properly.
As I do not print much, time will tell if it holds or not.

My printer is an inexpensive+basic Samsung / HP Xpress M2020W released ca. 2014, good enough* for what I need at home.
* no ethernet port, just WiFi (which I do not use) but given the price I paid for it cannot complain.

I managed to get it working by using the *.ppd file Samsung_M2020_Series.ppd extracted from a driver file named uld_V1.00.39_01.17.tar.gz downloaded directly from HP, which seems to be the last available version.

Note: it would seem that a file named rastertospl, located the uld/x86_64/ folder is also needed to get the printer working properly.
Otherwise you get an error message in the log which reads:

File "/usr/lib/cups/filter/rastertospl" not available: No such file or directory

It does not seem to be available in any Linux package and the problem is solved by copying it to that directory as root.
Now, with CUPS working properly, at boot time my /var/log/cups/error_log reads:

~$ cat /var/log/cups/error_log
W [24/Jun/2024:07:37:19 -0300] Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
~$ 

The link in the terminal printout redirects to this webpage which started getting comments in 02/2021, over three years ago.

"Printer drivers are deprecated and will stop working" reads just as forboding as when Nvidia dropped their legacy 340.108 drivers.
Hopefully I am wrong.

The whole thread I linked to above is pretty much printer protocols/drivers specific and is way over my head.

So the question is:
Anyone here at Dev1 use one of these printers (or any other printer needing a *.ppd) with CUPS without resorting to specific printer drivers?

Thanks in advance.

Best,

A.