Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: ExtremeFam07 on September 10, 2018, 05:44:04 AM
-
I hate asking for help. However, i am at a loss as to what the problem is. I've previously only use Rasbian or Arch. This is my first encounter with tiny core. If anyone is willing to help i would appreciate it greatly. My end goal to have a totally quiet boot with only a boot/start mp4 playing then straight into a single application (TunerStudio).
So my problem I'm having is getting my keyboard and mouse to work in the desktop. Its making me feel very dumb. Everything works great in CLI and quits as soon as i start X.
please advise on anything i can try my keyboard/mouse combo is Logitech K400 USB.
thank you,
-
Just to add to this. . . I have tried the current 9.0.3 for ARM6 and the ARM7 release as well as the current beta 10. i have set up WiFi and a swap partition and expanded the second partition. I've installed all the recommended extensions for WiFi and I even installed kbd to see if it would help. I am backing up every change I make between reboots. I have redone this all several times trying to get different outcome. This last time I actually remembered to install TC with -wo instead of the -wi. So at least I'm not stuck and have to start over as prior attempts left me. As Im sure you can tell I am no where knowledgeable enough on Linux.
-
Hi ExtremeFam07,
..So my problem I'm having is getting my keyboard and mouse to work in the desktop. Its making me feel very dumb.
..Try xsetup.sh command at command prompt to setup mouse .
.. Also check for more discusion on mouse setup : http://forum.tinycorelinux.net/index.php?topic=10731.0
-
Look in /var/log/Xorg.0.log after starting and killing X (via SSH or maybe a timed script).
-
Thank you so much Pats and curaga for replying. I may be missing something on my installs. As StartX says the desktop.sh file is missing. The only way I can boot into the desktop is with the command "TC". Here are the results from SSH when I tried the kill X command and also when checking for the detection of keyboard mouse. From the looks of it, it is seeing the correct hardware.
( '>')
/) TC (\ Core is distributed with ABSOLUTELY NO WARRANTY.
(/-_--_-\) www.tinycorelinux.net
tc@box:~$ kill X
-sh: invalid number 'X'
tc@box:~$ kill Xorg
-sh: invalid number 'Xorg'
tc@box:~$ cat /var/log/Xorg.0.log
cat: can't open '/var/log/Xorg.0.log': No such file or directory
tc@box:~$ cat /proc/bus/input/devices
I: Bus=0003 Vendor=046d Product=404d Version=0111
N: Name="Logitech K400 Plus"
P: Phys=usb-3f980000.usb-1.3:1
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2/0003:046D:C52B.0003/0003:046D:404D.0004/input/input0
U: Uniq=
H: Handlers=sysrq kbd leds mouse0
B: PROP=0
B: EV=12001f
B: KEY=3007f 0 0 0 0 483ffff 17aff32d bf544446 0 0 ffff0001 130f93 8b17c007 ffff7bfa d941dfff febeffdf ffefffff ffffffff fffffffe
B: REL=1c3
B: ABS=1 0
B: MSC=10
B: LED=1f
tc@box:~$
-
1) From Desktop , *Exit to prompt* option is avaliable.
2) Try to change run level with CTRL+ALT+F1 and set run level :
init 3
...Do your stuff and then set it back with command :
init 5
Use sudo for root if needed.
Generally it is useful to understand run levels ...
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this).
3) Pl check this link for more deatails on killing X session :
http://forum.tinycorelinux.net/index.php?topic=8045.0
4) For Tinycore concepts and different setups, perticularly : Xorg and Xvesa setups , pl read :
http://tinycorelinux.net/book.html
-
Hi Pats
From someone who would know:
In TC there are no run levels.
And straight from the source:
# /etc/inittab init(8) configuration for BusyBox
#
# Copyright (C) 1999-2004 by Erik Andersen <andersen@codepoet.org>
#
#
# Note, BusyBox init doesn't support runlevels. The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use sysvinit.
#
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# <id>: WARNING: This field has a non-traditional meaning for BusyBox init!
#
# The id field is used by BusyBox init to specify the controlling tty for
# the specified process to run on. The contents of this field are
# appended to "/dev/" and used as-is. There is no need for this field to
# be unique, although if it isn't you may have strange results. If this
# field is left blank, it is completely ignored. Also note that if
# BusyBox detects that a serial console is in use, then all entries
# containing non-empty id fields will be ignored. BusyBox init does
# nothing with utmp. We don't need no stinkin' utmp.
#
# <runlevels>: The runlevels field is completely ignored.
~SNIP~
Found here:
https://git.busybox.net/busybox/tree/examples/inittab?h=1_4_stable
-
@Rich,
Thanks for reminding abt "sysvinit" ! ... For a moment , had gone into old "init" days and forgot to mention "sysvinit" while quoting :
...Generally it is useful to understand run levels ...
The levels mentioned are just for info.
... "init" stands corrected , pl read as "sysvinit" !
-
I have been slowly going through "The Book" does anyone have an image of piCore that has already been remastered for a basic desktop environment with WiFi?
Thank you to everyone for the information I greatly appreciate it. I still have yet to get my keyboard to work in any desktop environment. I feel like I keep messing something up during my install process. What it could be I have not a clue. I think I might end up having to set up another Linux install. I haven't used Linux day to day in a while.
-
I noticed people having issues with the K400 usb from material about 5 or so years back. Could anything in there help:
https://wenlong.wordpress.com/2011/10/30/using-logitech-k400-wireless-keyboard-with-linux/
Things like battery tape-tabs, keyboard switch, plus version, unplugging any conflicting bluetooth etc etc.
Have you tested with another keyboard just to get you up and running until a solution is found?
-
I will have a look through that link and have a see. I haven't tried any other keyboard yet for two reason. First being it has worked great on every other OS I've tried it with. And secondly, I don't have another one I can use. I have it( the pi) embedded and have no room for a USB cable just the little dongle for the keyboard. I might have to get a different brand keyboard if that's all it would be.
Thank you,
-
I have a pretty similar issue but no X logs in /var
keyboard work fine in cmd line and when in X after startx mouse doesn't move with my K400+
SSH work fines
-
If I cat /dev/inputs/mice or mouse0 I see junk when mouse is moved.
Is there a configuration to get mouse to work in flwm (which I think is used)?
-
I did try another wireless mouse (another logitech unified) and it work correctly
My issue seem to be with my K400+ keyboard have not mouse not being used buy Xorg
Any idea?
-
Funny thing
After trying my performance MX mouse (which worked on PiCore) I put back my K400+ dongle and the mouse worked
I rebooted, didn't work. remove and replace the dongle still not working. put my MX dongle work then put back K400 one and work fines
what gets created when I put my other dongle in?
-
Hi julspower
what gets created when I put my other dongle in?
Possibly a driver that the non-working one needs? Try running:
lsmod > badmouse.txt
with it not working. Then plug in the other dongle so the mouse works and run:
lsmod > goodmouse.txt
Compare the two files to see if anything new was loaded.
-
thanks for pointing that
evdev wasn't loaded when its not working
If I get a console in ssh and I modprobe evdev everything is fine
A possible workaround is make it load with the .xsession script
-
sudo modprobe evdev
Enables the K400 keyboard and trackpad in the PiCore GUI, however, despite:
filetool.sh -b
does not survive reboot. To overcome the reboot hurdle add the instruction:
echo "sudo modprobe evdev" >> /opt/bootlocal.sh
save the instruction to survive reboot:
filetool.sh -b
-
Hi gatorback
sudo modprobe evdev
Enables the K400 keyboard and trackpad in the PiCore GUI, however, despite:
filetool.sh -b
does not survive reboot. ...
That's because you can't backup the memory that a driver was loaded into. The filetool.sh command only backs up files. I don't think
a driver that you modprobe manually would survive a reboot in any Linux.