-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#166
Ok, try kmathern's suggestion at boot menu.
-
Posts: 1,028
- Joined: 21 Aug 2011
#167
Booting with parameter xorg=sisimedia
produces a working desktop via the sismedia driver
Menus correctly populated with working conky and iceweasel.
Just doing that when you posted.anticapitalista wrote:Ok, try kmathern's suggestion at boot menu.
Booting with parameter xorg=sisimedia
produces a working desktop via the sismedia driver
Menus correctly populated with working conky and iceweasel.
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#168
Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
-
Posts: 1,028
- Joined: 21 Aug 2011
#169
How will that work on a system traditionally installed to hard disk?anticapitalista wrote:Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#170
BitJam may be able to weave some magic to do it automatically.
I hope that the live boot option would carry over to install.SamK wrote:How will that work on a system traditionally installed to hard disk?anticapitalista wrote:Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
BitJam may be able to weave some magic to do it automatically.
-
Posts: 1,028
- Joined: 21 Aug 2011
#171
I hope so too. It seems that everything is present and specifying the xorg=sisimedia boot parameter unassisted produces the desktop as expected, perhaps the detection mechanism might be able to be tweaked.anticapitalista wrote:I hope that the live boot option would carry over to install.SamK wrote:How will that work on a system traditionally installed to hard disk?anticapitalista wrote:Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
BitJam may be able to weave some magic to do it automatically.
-
Posts: 1,308
- Joined: 31 Aug 2009
#172
BTW, SamK, if you could boot with the"load=all" option and then attach (or send me) the /var/log/live/initrd.log file then I *might* be able to send a bug report upstream to report the problem with the sismedia driver not loading automatically. The"load=all" cheat should put the information needed into the initrd.log file.
The change should transfer automatically when you do an install. If it doesn't then fix the installer so it does not delete the xorg.conf file. That's all that is needed.SamK wrote:How will that work on a system traditionally installed to hard disk?anticapitalista wrote:Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
BTW, SamK, if you could boot with the"load=all" option and then attach (or send me) the /var/log/live/initrd.log file then I *might* be able to send a bug report upstream to report the problem with the sismedia driver not loading automatically. The"load=all" cheat should put the information needed into the initrd.log file.
-
Posts: 1,445
- Joined: 09 Feb 2012
#173
Today, after upgrading all antix* packages marked as upgradeable, a regression:
dynamic root persistence, semi-automatic
Shutdown asks Y/N to perform persist-save, even though persist-save was successfully performed just 5 seconds ago during desktop session exit.
@SamK
Psssst... controlPanel has been revised (notebook tab for Tools is now absent)
dynamic root persistence, semi-automatic
Shutdown asks Y/N to perform persist-save, even though persist-save was successfully performed just 5 seconds ago during desktop session exit.
@SamK
Psssst... controlPanel has been revised (notebook tab for Tools is now absent)
-
Posts: 88
- Joined: 25 Aug 2012
#174
I don't know if upstream will accept a bug report for the sisimedia driver, I don't think it's officially supported (not by Debian anyway).BitJam wrote:... I *might* be able to send a bug report upstream to report the problem with the sismedia driver not loading automatically. ...
-
Posts: 1,308
- Joined: 31 Aug 2009
#175
Somebody must be writing the driver. If we can determine which modalias is associated with the graphics card/chip then it should be trivial for the author of the driver to add it to an existing list of modaliases.kmathern wrote:I don't know if upstream will accept a bug report for the sisimedia driver, I don't think it's officially supported (not by Debian anyway).
-
Posts: 1,308
- Joined: 31 Aug 2009
#176
Thanks!skidoo wrote:dynamic root persistence, semi-automatic
Shutdown asks Y/N to perform persist-save, even though persist-save was successfully performed just 5 seconds ago during desktop session exit.
-
Posts: 1,308
- Joined: 31 Aug 2009
#177
@SamK, if you are running a LiveUSB you can add this option to your bootloader by editing the file /live/boot-dev/boot/syslinux/options.men. Add a line like this:The separation character is back-tic which on my keyboard is on the upper left-hand corner near <Escape>.
To make F8-Save work with this entry, you will also have to edit the gfxsave.cfg file and add"|xorg" to the end of the Options line so it becomes:
On the LiveUSB, many of the bootloader menus can be edited by the user.anticapitalista wrote:Excellent! So it does work, but not automatically. I guess having F4 SIS option might be useful
@SamK, if you are running a LiveUSB you can add this option to your bootloader by editing the file /live/boot-dev/boot/syslinux/options.men. Add a line like this:
Code: Select all
sis graphics `xorg=sisimedia
To make F8-Save work with this entry, you will also have to edit the gfxsave.cfg file and add"|xorg" to the end of the Options line so it becomes:
Code: Select all
Options|options|checkmd5|checkfs|toram|automount|mount|nousb2|acpi|from|hwclock|xorg
-
Posts: 1,445
- Joined: 09 Feb 2012
#178
As of today's update, /usr/local/share/excludes/live-remaster-exclude.list the pattern anchor (forward slash) is absent from each entry... and this worries me.
Remember the discussion thread where a guy ran into problems b/c the"media" (IIRC) subdirectory of an installed app wound up being excluded?
I had hoped that each of the several excludes files would be migrated to explictly show the implicit (?user wonders) leading slash anchor.
In any event, some of the excludes currently files contain patterns bearing leading slash (for each pattern), other excludes files do not... invites confusion.
A fifth"excludes" file has been introduced ~~"general-remaster-exclude.list". Although it might be obvious, a comment in the header would be helpful:
"entries in this 'general' items are also excluded during 'live' remaster" that is, if I'm correctly inferring the list's purpose
Similarly, in the comment header of live-remaster-excludes.list,"during live remaster, these entries along with 'general-remaster-exclude.list' entries are excluded"
On a related note, with scriptfiles in general, it's often not obvious"How did we get here?"
Yes, it's somewhat helpful to read"this script does blablah during shutdown" but it would be hugely helpful to read, in a header comment:
"this script is called by /path/to/calling/script.sh and /path/to/another/caller"
If the puzzle pieces change over time, and some breadcrumbs become inaccurate, would still provide an overall benefit.
Remember the discussion thread where a guy ran into problems b/c the"media" (IIRC) subdirectory of an installed app wound up being excluded?
I had hoped that each of the several excludes files would be migrated to explictly show the implicit (?user wonders) leading slash anchor.
In any event, some of the excludes currently files contain patterns bearing leading slash (for each pattern), other excludes files do not... invites confusion.
A fifth"excludes" file has been introduced ~~"general-remaster-exclude.list". Although it might be obvious, a comment in the header would be helpful:
"entries in this 'general' items are also excluded during 'live' remaster" that is, if I'm correctly inferring the list's purpose
Similarly, in the comment header of live-remaster-excludes.list,"during live remaster, these entries along with 'general-remaster-exclude.list' entries are excluded"
On a related note, with scriptfiles in general, it's often not obvious"How did we get here?"
Yes, it's somewhat helpful to read"this script does blablah during shutdown" but it would be hugely helpful to read, in a header comment:
"this script is called by /path/to/calling/script.sh and /path/to/another/caller"
If the puzzle pieces change over time, and some breadcrumbs become inaccurate, would still provide an overall benefit.
-
Posts: 1,308
- Joined: 31 Aug 2009
#179
I can use either format. If there is significant support for one format over the other than I will use it. I can't tell the mx-snapshot dev what to do and his choices will be reflected in our own iso-snapshot program.
This is the native format for the mksquashfs program which uses this information. I discussed this with the mx-snapshot dev and he preferred to use the native mksquashfs format instead of the more sensible format with a leading slash. So I was torn between being compatible with the mx-snapshot or using a format I think makes sense. I don't think there is a good answer here.skidoo wrote:As of today's update, /usr/local/share/excludes/live-remaster-exclude.list the pattern anchor (forward slash) is absent from each entry... and this worries me.
I can use either format. If there is significant support for one format over the other than I will use it. I can't tell the mx-snapshot dev what to do and his choices will be reflected in our own iso-snapshot program.
-
Posts: 1,445
- Joined: 09 Feb 2012
#180
Thanks for the explanation, BitJam. I'll respect the script maintainer's preference and not press the issue.