topic title: antiX-16-b2.1-full available
Posts: 1,028
SamK
Joined: 21 Aug 2011
#91
dolphin_oracle wrote:another thing to try.
[...]
I don't know if it affects this mouse issue, but it shouldn't hurt to try it.
Using a fresh USB installation of 16-b2.1
root persistence enabled
Using shipped Intel video driver
Create etc/X11/xorg.conf.d/intel-video.conf

Code: Select all

Section       "Device"
   Identifier "card0"
   Driver     "intel"
   Option     "AccelMethod" "uxa"
EndSection
Reboot

Result:
The mouse cursor is displayed on the desktop as expected. Looks like another way to fix the problem.

Perhaps someone else might also test on different kit to confirm.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#92
antiX Control Center Disks

Suggestions
  • The label for Unetbootin be changed to Install to a partition on USB
  • The label for antiX2usb be changed to Install to the entire USB
All items in the Disks section will then express their function in terms of the action to be conducted. The changes will make the section more coherent and more immediately understandable.
Illustrating labels to change
Illustrating labels to change
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#93
antix2usb can actually install the iso to a section of the usb device but not to a pre-partitioned one (yet).
You are given the option to install to full disk or part of the disk. Once antiX2usb has finished, then user can fornat the rest with gparted,
Posts: 1,028
SamK
Joined: 21 Aug 2011
#94
antiX Control Center Disks
anticapitalista wrote:antix2usb can actually install the iso to a section of the usb device but not to a pre-partitioned one (yet).
You are given the option to install to full disk or part of the disk. Once antiX2usb has finished, then user can fornat the rest with gparted,
Fair enough. Until antiX2usb can handle existing partitions, here's another (alternative) wording suggestion.

Unetbootin might be Install USB retain partitions
antiX2usb might be Install USB delete partitions
Posts: 1,028
SamK
Joined: 21 Aug 2011
#95
Re: High System Load

Initial tests with intel-video.conf show no sings of the high system load cycles
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#96
thanks for testing that sam.

I think this also clears up some strange graphical artifacts I've seen from time to time in mx-15.


edit


information on available intel chipsets.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units"
linktext was:"https://en.wikipedia.org/wiki/List_of_I ... sing_units"
====================================



I don't know how to handle this in antiX, but it is technically possible to sort out which part requires UXA and which are SNA capable.

Or you know, just use the older debian drivers.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#97
dolphin_oracle wrote:thanks for testing that sam.
If you ever stumble across the reason why the driver without the extra configuration, works with 1 of 3 WMs on the same system, let me know. It is really odd.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#98
SamK wrote:
dolphin_oracle wrote:thanks for testing that sam.
If you ever stumble across the reason why the driver without the extra configuration, works with 1 of 3 WMs on the same system, let me know. It is really odd.
I will. I've also made this change to my MX XFCE system, and some corrupted text issues that I've had ever since launch are gone, or at least greatly diminished in frequency.
Posts: 452
Jerry
Joined: 12 Sep 2007
#99
Probably be good to post that on the Dev Team forum, if you hadn't already thought of doing that...
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#100
Jerry wrote:Probably be good to post that on the Dev Team forum, if you hadn't already thought of doing that...
Good idea. still trying to pin down what's going on.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#101
Re: Invisible Mouser Cursor
dolphin_oracle wrote:still trying to pin down what's going on.
Because of the results in this post
post46464.html#p46464
It might be there are multiple aspects to this condition and they may be masking or interacting with each other. Changing the driver or driver configuration is not necessarily fixing all aspects. It might be just be allowing a different result of any interaction to be shown.

From the above link, which shows the driver shipped in 16-b2.1, three factors stand out:
  1. JWM variants work as expected
  2. Fluxbox and IceWM variants all fail
  3. Restarting a failed WM via its respective restart item in the antiX main menu,"fixes" the problem
#3 might indicate something is happening out of sequence or is unable to finish and is being held in an incomplete state. A restart of the WM might just be allowing the blockage to be released.

The behaviour is reminiscent of a condition reported throughout the development of 15 in which the IceWM taskbar monitors freeze during boot up. That condition is also able to be"fixed" by restarting the WM. It might be another symptom of a wider problem.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#102
SamK wrote:Re: Invisible Mouser Cursor
dolphin_oracle wrote:still trying to pin down what's going on.
Because of the results in this post
post46464.html#p46464
It might be there are multiple aspects to this condition and they may be masking or interacting with each other. Changing the driver or driver configuration is not necessarily fixing all aspects. It might be just be allowing a different result of any interaction to be shown.

From the above link, which shows the driver shipped in 16-b2.1, three factors stand out:
  1. JWM variants work as expected
  2. Fluxbox and IceWM variants all fail
  3. Restarting a failed WM via its respective restart item in the antiX main menu,"fixes" the problem
#3 might indicate something is happening out of sequence or is unable to finish and is being held in an incomplete state. A restart of the WM might just be allowing the blockage to be released.

The behaviour is reminiscent of a condition reported throughout the development of 15 in which the IceWM taskbar monitors freeze during boot up. That condition is also able to be"fixed" by restarting the WM. It might be another symptom of a wider problem.
Fair points.

I disconnected my netbook (EEEPC 904ha) from its media-player duties and yes, it exhibits the invisible cursor problem.

All window managers exhibit the problem. jwm hides it a little better than the others because, unlike fluxbox and icewm, it looks like jwm restarts in normal course at boot up. The mouse cursor is invisible until the jwm restart. Its quite possible that sam's result with min-jwm failing is due to the fact the min-jwm for whatever reason doesn't restart when it loads (it doesn't as far as I can tell). for the record, min-jwm also fails to show a cursor for me, but the rox and spacefm jwm(s) do show a mouse cursor (after the normal startup restart).

the mouse cursor should appear as soon as login from slim is achieved. it should appear even before taskbars and such. its invisible in all three wm's, including jwm, just after login in. However, jwm restarts either just before or just after conky loads (my machine is slow, so its hard to tell). When that restart happens, the cursor appears. Does the menu still update at boot....its possible that jwm is restarted after the menu update.

I've also tested the notion that just the act of making a setting change to the intel driver is enough to clear the issue. Its not. I've tried two other options (TearFree and then actually setting AccelMethod to sna explicitly) and neither of those worked to produce a mouse cursor at first boot.

so my current theory is actually this: jwm (rox and spacefm) shows a cursor because of something in the startup chain after X loads, rather than something in the startup chain causing the others to fail. They actually all fail, jwm just fails more gracefully than the others.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#103
dolphin_oracle wrote:...jwm hides it a little better than the others because, unlike fluxbox and icewm, it looks like jwm restarts in normal course at boot up.
Excellent point. I had completely forgotten about this. It is a credible explanation of what now appears to be the illusion of the main JWM variants succeeding.

As far as I can recall, JWM does something that Fluxbox and IceWM, don't. As part of the menu update routine JWM invokes a restart of itself. This is the equivalent of restarting the others from their respective restart items in the antiX main menu. Each of these actions release the blockage and shows the cursor.

JWM-Min does not appear to update the menu hence there is no restart of JWM and the mouse remains invisible. In this state, doing a manual update of the menu via the antiX main menu, invokes the restart of JWM and the mouse is shown.
dolphin_oracle wrote:the mouse cursor should appear as soon as login from slim is achieved. it should appear even before taskbars and such. its invisible in all three wm's, including jwm, just after login in.
Does the fact that it does not do this potentially implicate the changes made to slim.conf in antiX subsequent to 13.2?
dolphin_oracle wrote:so my current theory is actually this: jwm (rox and spacefm) shows a cursor because of something in the startup chain after X loads, rather than something in the startup chain causing the others to fail. They actually all fail...
My interpretation of the tests supports this analysis.

Additionally, while testing 16-b2.1, the frozen IceWM taskbar monitors reported throughout the development of 15 has been observed again. It is also"fixed" by restarting the WM. After the release of 15 I tried using a workaround to handle this problem. An IceWM restart command was added to the end of the startup chain. It does work but was abandoned on the grounds that it did not address the root cause of the problem and introduced unwanted and ugly flashing of the screen during the restart.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#104
SamK wrote:
dolphin_oracle wrote:the mouse cursor should appear as soon as login from slim is achieved. it should appear even before taskbars and such. its invisible in all three wm's, including jwm, just after login in.
Does the fact that it does not do this potentially implicate the changes made to slim.conf in antiX subsequent to 13.2?
actually I think it more supports the video driver issue. on hardware that can use sna, and older hardware with uxa specified, or with the older jessie intel driver, the mouse cursor is present as soon as login is finished.

SamK wrote: Additionally, while testing 16-b2.1, the frozen IceWM taskbar monitors reported throughout the development of 15 has been observed again. It is also"fixed" by restarting the WM. After the release of 15 I tried using a workaround to handle this problem. An IceWM restart command was added to the end of the startup chain. It does work but was abandoned on the grounds that it did not address the root cause of the problem and introduced unwanted and ugly flashing of the screen during the restart.
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.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#105
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.