LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020
OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Since this is 'testing' and I see no other problems with the 4.13 I say live with it with a warning in the thread. 4.12.10 would be my second choice. The problem is that /proc/cpuinfo is not being generated correctly by the kernel. Here is the core of a watch script that does work in 4.13.peebee wrote:OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
Code: Select all
#!/bin/sh
# Fails in 4.13 kernel
# lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /proc/cpuinfo | grep "^[c]pu MHz""
# Works on cpu0, could be expanded
lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Thanks Jim - that was the clue that google wanted ....Marv wrote:The problem is that /proc/cpuinfo is not being generated correctly by the kernel.
https://www.phoronix.com/scan.php?page= ... Management
http://lkml.iu.edu/hypermail/linux/kern ... 01366.html- x86 systems will no longer try to export their current CPU frequency to /proc/cpuinfo. There's also a way to rework how the CPU frequency is exported via sysfs too, using the registers for computing the current frequency rather than relying upon the CPUFreq driver.
- Stop trying to export the current CPU frequency via /proc/cpuinfo
on x86 as that is inaccurate and confusing (Len Brown).
- Rework the way in which the current CPU frequency is exported by
the kernel (over the cpufreq sysfs interface) on x86 systems with
the APERF and MPERF registers by always using values read from
these registers, when available, to compute the current frequency
regardless of which cpufreq driver is in use (Len Brown).
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Hi peebee,
In your next kernel build could you changeto
? In reading about the power management changes in 4.13 I came across it. schedutil is supposed to be the replacement for conservative, is actively supported, and what benchmarks I've seen look quite good.
In your next kernel build could you change
Code: Select all
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
Code: Select all
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
connecting wifi
Peebee
I am on a new laptop. I tried fatdog64, but soon moved to the RC's for xenialpup and slacko. I even tried debian stretch and slackware current (live).
Recently I turned to your LxPupSc which is excellent for new machines, not to say the best. It also brings back a bit the feel of saluki/carolina to me; I don't know why exactly. Thank you for this.
On version 17.08.23 I had to choose "CRD: 00 UNSET" for wifi. I still had to link /usr/local/simple_network_setup/rc.network in /root/Startup/ to have connection on startup. I also tried "CRD: BE Belgium", but automatic startup did not work, not even with the link, and in SNS "connect now" did not work (the profile seemed lost), so SNS had to scan for wifi connections every time again.
I am on version 17.09.21 now, and the above now works fine: "CRD: BE Belgium", persistence in SNS and even automatic connection on startup (without the link in ~/Startup).
However, the connection takes a long time. I had discovered before on version 17.08.23, executing rc.network in terminal with --verbose, that with "CRD: BE Belgium" /usr/sbin/connectwizard_crd is executed and the following errors occur:
/usr/sbin/connectwizard_crd: line 15: iw: command not found
/usr/sbin/connectwizard_crd: line 21: iw: command not found
....
The second error is repeated a lot of times and this takes a long time.
I comment this line out fttb, because I do not know how to correct the command.
EDIT: I cannot say connection time is shorter though: it remains around 1 minute.
Just one other thing puzzles me: I found another rc.network file at /etc/rc.d/
I am on a new laptop. I tried fatdog64, but soon moved to the RC's for xenialpup and slacko. I even tried debian stretch and slackware current (live).
Recently I turned to your LxPupSc which is excellent for new machines, not to say the best. It also brings back a bit the feel of saluki/carolina to me; I don't know why exactly. Thank you for this.
On version 17.08.23 I had to choose "CRD: 00 UNSET" for wifi. I still had to link /usr/local/simple_network_setup/rc.network in /root/Startup/ to have connection on startup. I also tried "CRD: BE Belgium", but automatic startup did not work, not even with the link, and in SNS "connect now" did not work (the profile seemed lost), so SNS had to scan for wifi connections every time again.
I am on version 17.09.21 now, and the above now works fine: "CRD: BE Belgium", persistence in SNS and even automatic connection on startup (without the link in ~/Startup).
However, the connection takes a long time. I had discovered before on version 17.08.23, executing rc.network in terminal with --verbose, that with "CRD: BE Belgium" /usr/sbin/connectwizard_crd is executed and the following errors occur:
/usr/sbin/connectwizard_crd: line 15: iw: command not found
/usr/sbin/connectwizard_crd: line 21: iw: command not found
....
The second error is repeated a lot of times and this takes a long time.
I comment this line out fttb, because I do not know how to correct the command.
EDIT: I cannot say connection time is shorter though: it remains around 1 minute.
Just one other thing puzzles me: I found another rc.network file at /etc/rc.d/
Interim delta to LxPupSc-17.09.24T-k64
- Kernel 4.13.3-lxpup64 including @Marv's requested CONFIG_CPU_FREQ_GOV_SCHEDUTIL
- Slackware-Current to Tue Sep 19 20:49:07 UTC 2017
iw has been added as reported by @foxpup
- Kernel 4.13.3-lxpup64 including @Marv's requested CONFIG_CPU_FREQ_GOV_SCHEDUTIL
- Slackware-Current to Tue Sep 19 20:49:07 UTC 2017
iw has been added as reported by @foxpup
Last edited by peebee on Thu 21 Sep 2017, 20:06, edited 1 time in total.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
23T updated to 24T using the delta. md5sum correct, nothing of note in the update so far. Radkys PupSysInfo 2.7.3 now reports CPU speeds correctly in 4.13 kernels, as does the little cpuwatch I used in my post above (cpu* replaces cpu0). Inxi, hardinfo and wcpufreq don't as yet. The schedutil governor now shows up and runs (Thanks!). It will take a bit to see how I like it but at first glance I think it is a bit more 'adaptive' than conservative. The difference in PupSysinfo and cpuwatch speeds is because the PupSysInfo information was grabbed before starting glxgears and the cpuwatch is dynamic with a 1 sec grab time.
Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
- Attachments
-
- screenshot.png
- (204.7 KiB) Downloaded 1351 times
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Thanks @Marv - wcpufreq was apparently developed by tazoc who sadly hasn't been on the forum since 2013....Marv wrote:Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
The .pet is in noarch-official so if you send me the changes I'll upload a new version....
Cheers
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Anybody else noticed that the 64-bit kernel makes lsmod report module size differently to the 32-bit kernel? First 64-bit 'oddity' that I've noticed - doesn't seem to have any further ramifications??
Kernel 4.9.50 32-bit gives:Kernel 4.13.3 64bit gives:
Kernel 4.9.50 32-bit gives:
Code: Select all
Module Size Used by
iptable_filter 1379 0
ip_tables 9625 1 iptable_filter
snd_hda_codec_via 9338 1
snd_hda_codec_generic 49158 1 snd_hda_codec_via
rt2800usb 16439 0
rt2x00usb 7961 1 rt2800usb
rt2800lib 69770 1 rt2800usb
rt2x00lib 32058 3 rt2800lib,rt2800usb,rt2x00usb
mac80211 328553 3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211 220211 2 rt2x00lib,mac80211
crc_ccitt 1195 1 rt2800lib
rfkill 8235 1 cfg80211
usblp 9474 0
snd_pcsp 6269 0
nouveau 1313442 2
mxm_wmi 1203 1 nouveau
wmi 6184 2 mxm_wmi,nouveau
i2c_algo_bit 4516 1 nouveau
ttm 64138 1 nouveau
drm_kms_helper 99176 1 nouveau
k10temp 2160 0
syscopyarea 2990 1 drm_kms_helper
hwmon 6646 2 k10temp,nouveau
Code: Select all
Module Size Used by
iptable_filter 16384 0
ip_tables 24576 1 iptable_filter
cpufreq_ondemand 16384 2
snd_hda_codec_via 20480 1
snd_hda_codec_generic 53248 1 snd_hda_codec_via
arc4 16384 2
joydev 20480 0
rt2800usb 24576 0
rt2x00usb 20480 1 rt2800usb
rt2800lib 90112 1 rt2800usb
rt2x00lib 40960 3 rt2800lib,rt2800usb,rt2x00usb
mac80211 303104 3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211 221184 2 rt2x00lib,mac80211
usblp 20480 0
rfkill 20480 1 cfg80211
crc_ccitt 16384 1 rt2800lib
nouveau 1359872 2
k10temp 16384 0
mxm_wmi 16384 1 nouveau
wmi 20480 2 mxm_wmi,nouveau
video 32768 1 nouveau
hwmon 16384 2 k10temp,nouveau
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
LxPupSc-17.10.1T-k64
LxPupSc-17.10.1T-k64 is a 32-bit woof-ce 'testing' branch build with a 64-bit kernel (therefore only compatible with 64-bit capable processors)
LxPupSc-17.10.1T-k64.iso {devx} - (devx does not include kernel sources or headers) {kernel 4.13.4-lxpup64 sources}
iso md5 = c1aa378bb649ef6dc658e7d224a97d9f
Delta from 17.09.1T is available
- kernel 4.13.4 64-bit (alternative 32-bit kernels 3.16.x 4.4.x & 4.9.x also available - all need firmware in the fdrv)
- Made from Slackware-Current as of Fri Sep 29 22:58:54 UTC 2017
- BUILD_FROM_WOOF='testing;3b243afd;2017-09-30 22:50:06 +0800'
- web browser in adrv is light-48.0
- firmware is in fdrv
- alternative fall-back xorg is in ydrv (no need to install unless needed)
**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with it's own devx is suggested but use the kernel sources above
Woof-CE build repository is: http://smokey01.com/peebee/slackocurrent/
Chromium, Firefox, Palemoon and Seamonkey are in the repository and installable via Internet -> Get Web Browser
The versions of the browsers as of 29-sep-2017 with their md5sums are:
chromium-61.0.3163.100+pepper_27.0.0.130 :ca66b7319051449bb86e344a6eeca705
firefox-52.4.0esr :b98370e14612b90d2d69b5775a423504
palemoon-27.5.0 :79c6305526f567792be7d3f3d4d61a2f
seamonkey-2.48 :05b91afef8b60bda21343a45da0aae49
firefox-56, vivaldi and min are also available
LxPupSc-17.10.1T-k64.iso {devx} - (devx does not include kernel sources or headers) {kernel 4.13.4-lxpup64 sources}
iso md5 = c1aa378bb649ef6dc658e7d224a97d9f
Delta from 17.09.1T is available
- kernel 4.13.4 64-bit (alternative 32-bit kernels 3.16.x 4.4.x & 4.9.x also available - all need firmware in the fdrv)
- Made from Slackware-Current as of Fri Sep 29 22:58:54 UTC 2017
- BUILD_FROM_WOOF='testing;3b243afd;2017-09-30 22:50:06 +0800'
- web browser in adrv is light-48.0
- firmware is in fdrv
- alternative fall-back xorg is in ydrv (no need to install unless needed)
**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with it's own devx is suggested but use the kernel sources above
Woof-CE build repository is: http://smokey01.com/peebee/slackocurrent/
Chromium, Firefox, Palemoon and Seamonkey are in the repository and installable via Internet -> Get Web Browser
The versions of the browsers as of 29-sep-2017 with their md5sums are:
chromium-61.0.3163.100+pepper_27.0.0.130 :ca66b7319051449bb86e344a6eeca705
firefox-52.4.0esr :b98370e14612b90d2d69b5775a423504
palemoon-27.5.0 :79c6305526f567792be7d3f3d4d61a2f
seamonkey-2.48 :05b91afef8b60bda21343a45da0aae49
firefox-56, vivaldi and min are also available
- Attachments
-
- Screenshot.png
- (121.34 KiB) Downloaded 947 times
Last edited by peebee on Sun 01 Oct 2017, 17:24, edited 1 time in total.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.
The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.
The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Oops - fixed md5 for iso...aboveMarv wrote:Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.
The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.
There have been kernel changes - hibernation, your cpu frequency module, some BarryK suggestions from his blog....??
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Seems to occur pretty sharply with the 4.12 to 4.13 kernel transition so far as I can see. I'll have a look at the 4.13.0 dotconfig, I think it predates most of those other changes and still shows the anomaly. I also see identical behavior in battleshooters 4.13.x series kernels and in yours. I also have installed gvfs 1.30.4 (from an 0ubuntu deb) with no change in behavior. I'm running the 4.12.10-lxPup64 kernel in LxPupSc 17.10.1T-64 right now.peebee wrote:Oops - fixed md5 for iso...aboveMarv wrote:Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.
The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.
There have been kernel changes - hibernation, your cpu frequency module, some BarryK suggestions from his blog....??
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Hi Peebee,
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
- Attachments
-
- laptop-keyboard.jpg
- (163.04 KiB) Downloaded 1583 times
belham2 wrote:Hi Peebee,
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
Just wanted to followup on the question I posted above: figured this much out. One of the files in /root/.config/openbox is the rc.xml file & it seems to be involved in this problem (editing the lxde-rc.xml seems to do nothing). I found an entry in it for 'mtpaint' mapped to key "0x6F", whatever that is. Putting a # before all the lines for this entry mapping stopped 'mtpaint -s' from launching when hitting the "Up" key. But then the "Up" is no longer functional, does nothing. And the bigger problem is, on reboots, my changes to this 'rc.xml' are getting wiped and the launching of 'mtpaint -s' is back again on my "Up" arrow key.
Anyone can steer me in the right direction to fix this permanently? Thank you.
[Edit: fixed, made changes in both lxde-rc.xml & rc.xml, and both held with reboots. Also re-mapped this laptop's F2 thru F6 functions keys: now have working F2 (sound on/off), F3 (sound decrease), F4 (sound increase), F5 (redshiftgui-screen brightness decrease) and F6 (redshiftgui-screen brightness increase). And the "Up" arrow is now blessedly functioning as normal; goodbye to the 'mtpaint -s' launching madness ]
Sorry, I just saw this now. I did connect directly from PCManFM using gvfs and test. I get the same slow 3 minute or more transfer time for the 256Mb savefile. I 'think' that gvfs is the problem but I've checked its versions as well as libsmbclient etc. and they are all either the most recent or updating them gave no change in speeds. Kernel 4.13 did change the default cifs mount to SMB3 from SMB1 but locking my samba server to SMB1, SMB2, or SMB3 gives me no change in the speeds. I normally run with it locked to SMB3 to minimise negotiation and with strict allocate =yes. cli, rsync and Rox-Filer transfers always great no matter what the configuration. Thunar and PCManFM slow. The only common denominator I see is gvfs/kernel interaction but I'm kind of stuck there for now.rcrsn51 wrote:Hi Marv:
Just out of curiosity, if you didn't mount the share in YASSM and let gvfs handle everything, does it make a difference?
Bill
Jim
Last edited by Marv on Tue 03 Oct 2017, 21:59, edited 1 time in total.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Hi - I don't see this problem on LxPupSc..... I checked with a pristine frugal install and the keys all worked as expected.belham2 wrote:Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot
Was your install using an existing save folder? What had you installed? Have you done any theme changes in LXDE or in JWM?
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
I also have this on my keyboard. I just edit /root/.config/openbox/rc.xml andCan you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot?
find the lines that call mtpaint and change it to:
Code: Select all
<keybind key="111">
<action name="Execute">
<startupnotify>
<enabled>true</enabled>
<name>Print Screen</name>
</startupnotify>
<command>mtpaint -s</command>
</action>
</keybind>