SamK wrote:

dolphin_oracle wrote:are they still frozen with the"uxa" thing. I'm still not completely convinced they are the same problem, but it doesn't hurt to check.

Currently I'm testing in live with root persistence using etc/X11/xorg.conf.d/intel-video.conf. The freezing certainly happens in this environment. I didn't focus on this aspect when testing using the driver from Debian instead, so cannot recall whether it happens in that configuration.

dolphin_oracle wrote:I'm thinking something else is going on. For instance, I currently have no mouse cursor (no intel-video.conf modifications) and I enabled the tray monitors in ~/.icewm/preferences, but the monitors work upon login but still no mouse.

So it well could be something else effecting in the slim and forward setup.

We can eliminate slim by booting to init 3 and using startx.

anticapitalista wrote:dolphin_oracle - is that using the debian intel drivers?

dolphin_oracle wrote:So it well could be something else effecting in the slim and forward setup.

We can eliminate slim by booting to init 3 and using startx.

dolphin_oracle wrote:Boot on machine with tray monitors enabled. confirm frozen at startup (rather than just black at start, which is what mine look like, even though they are running).

• The monitors are displayed with the desktop as expected
• Initially both are working i.e. their indicator lines are scrolliiong across their respective monitor boxes
• After approx 2 seconds both freeze i.e. they stop scrolling and remain inactive with indicator lines displayed in an unchanging state in their monitor boxes
• A restart of IceWM resets the boxes to blank, they again begin scrolling, and work as expected thereafter

SamK wrote:

dolphin_oracle wrote:Boot on machine with tray monitors enabled. confirm frozen at startup (rather than just black at start, which is what mine look like, even though they are running).

A more detailed description of"frozen" follows. Only CPU and Network monitors are tested.

In all cases:

• The monitors are displayed with the desktop as expected
• Initially both are working i.e. their indicator lines are scrolliiong across their respective monitor boxes
• After approx 2 seconds both freeze i.e. they stop scrolling and remain inactive with indicator lines displayed in an unchanging state in their monitor boxes
• A restart of IceWM resets the boxes to blank, they again begin scrolling, and work as expected thereafter

To summarise, the monitors in the IceWM system tray load with the desktop as expected, begin working as expected, then freeze. Something is stopping the continued operation after they visibly are working correctly. A restart of the WM returns them to a fully operational state which is then maintained.

@dolphin_oracle, anticapitalista
It is going to be some hours, possibly a day before I can begin further tests.

dolphin_oracle wrote:do the monitors"stick" when using min-icewm?

cat /proc/cmdline
desktop=min-icewm vga=791 persist_root lang=en_GB quiet splash=off disable=lx

ps -e | grep desktop-session
 3527 ?        00:00:00 desktop-session

SamK wrote:

dolphin_oracle wrote:do the monitors"stick" when using min-icewm?

I now have the view that using min-icewm or min-anything as a reference point is invalid. My previous understanding was min-* did not employ the desktop-session chain. This is not the case as demonstrated by the following system booted to min-icewm.

Code: Select all

cat /proc/cmdline
desktop=min-icewm vga=791 persist_root lang=en_GB quiet splash=off disable=lx

ps -e | grep desktop-session
 3527 ?        00:00:00 desktop-session

This clearly illustrates a desktop-session process is used.

It led me to think in a different direction about the matters being tested. I have now been able to boot the system so both the mouse cursor and the monitor work as expected. I want to recheck my procedure and results before posting. I have not forgotten the awaited test. It is just being delayed a little.