Touchpad disabled on KDE login

Hi,
this is driving me crazy: the touchpad is enabled in KDM, but during the KDE login the touchpad gets disabled. So I always have to open a konsole and do "xinput enable 12" (id of the touchpad).
Can't figure out why it started happening.

Not a fix, but as workaround you could add "xinput enable 12" to the kde autostart on "System settings -> Start & Shutdown [system administration section] -> add program"
pd: section names can vary, my kde isn't on english
Last edited by mzneverdies (2013-03-20 10:57:19)

Similar Messages

Macbook air with 10.10.1 keyboard and touchpad stop responding after login screen

Keyboard and touchpad works only at login screen.
I have tried all the PRAM and SMC. reset stuff.
Safe mode, repair etc. Creating another account is not helped either.
I am also using 10.10.1 with macbook air.
I have also called the apple tech support and no results!
And this is obviously a software bug from so called robust yosemite!
Same here!
Macbook air built-in keyboard/trackpad only work at login screen

You may have to take the computer to the Apple store to have it checked out.
Genius Bar reservation
http://www.apple.com/retail/geniusbar/
Best.

How to disable the guest login in OBIEE 11g?

Hi,
Whenever i click on analytics link, Guest automatically logs in , then i have to logout in order for the user to log in.
How do we disable this Guest login?
Thanks
Ashish

Hi,
Whenever i click on analytics link, Guest automatically logs in , then i have to logout in order for the user to log in.
How do we disable this Guest login?
Thanks
Ashish

T60; Touchpad disabled; No "Touchpad" option on BIOS

dear community members,
since I restaged XP, my touchpad isn't working and is permanently disabled. Symptoms are:
a) On ThinkPad Configuration utility, the TouchPad item is grayed and can't be checked
b) when Fn+F8, three options appears: (1) Enable trackpoing and touchpad (2) Enable trackpoint only (3) Enable touchpad only. Even when I choose option (1), the touchpad isn't enabled
c) when launching UltraNav wizard, message is: "Touchpad is disabled from BIOS. Please enable it from BIOS or the ThinkPad configuration utility"
d) on the BIOS utility, there is no option for Touchpad under Config/Keyboard Mouse
BIOS was updated today
Trackpoint works OK
UltraNav shows Touchpad disabled (grayed)
Device manager doesn't shows any error.
Can someone understand what is happening ?
Regards

hi
İ am same ploblem in my t61 do you have any idea or have you resolved this problem
Thanks &Regards
Murat CIRBAN

How do I disable the GUEST login option at start up screen

how do I disable the GUEST login option at start up screen.
I have already gone to
System Pref'>Users and Groups>Unlocked it with password>Guest User is OFF>Allow guests to log into this computer is NOT CHECKED,
however I still have that GUEST USER selection on the login screen.

Hello Leopardus,
having read other post concerning this issue
Re: Removing Guest User icon from login page
dated all the way back to 2012, I have decide to leave well enough along and not let the GUEST button bother me.
I rarely if ever take my Mac out of the house so I have not given much thought to theft or loss, but, in the event of it leaving my house by another way, the slim possibility of recovering it is worth the annoyance, I'll get over it.
Thank you all.

How can we disable user to login Hyperion Workspace

We understand we can set to admin mode for Hyperion Planning so that only administrator can login the system. Any other ways to disable users to login Hyperion Workspace? We are using Hyperion version 11.1.1.1
Thanks a lot!

JohnGoodwin wrote:
Hi,
Just to confirm you want to stop users creating Financial reports using the Reporting Studio? If so then you would remove the role of "Report Designer" in there provisioning.
Cheers
John
http://john-goodwin.blogspot.com/
Thanks John. We just want to disable user using FR report prepared in Reporting Studio and put under "Explore" of Workspace. We found that we can't do that once the user is login into Workspace. The only way we can do is to setup the security setting of each FR report based on the group setting.

Is there a way to decrypt the SQL login-only encryption in the netmon trace or disable the SQL login-only encryption?

We know by default the SQL Server use the self-signed certificate to encrypt the SQL login information when building the connection, my question is if
there is a way to decrypt the SQL login-only encryption in the netmon trace or disable the SQL login-only encryption?
Please click the Mark as Answer button if a post solves your problem!

Not without login as admin. To avoid using credentials to login to SQL, use Windows Credentials instead.
jdweng

Disable the database login

Hi All,
I'm working on soa 11.1.1.5 version.I don't want to store my each and every payload in the related database in the dev environment to overcome the heavy burden.I have to disable the database login in my composite application.By using which bpel property i can disable the database login.Where can i check the payload details in the database.
Anybody Please give me your valuable suggestions.
Thanks in advance!
Edited by: 851924 on Jul 2, 2012 2:17 AM

Thank you so much for your reply Arik,i have configured the below properties in my composite.xml file
<component name="BPELProcess" version="2.0">
<implementation.bpel src="BPELProcess.bpel"/>
<property name="bpel.config.auditLevel">Production</property>
</component>
can u please let me know the difference with below configuration....
<component name="BPELProcess" version="2.0">
<implementation.bpel src="BPELProcess.bpel"/>
<property name="bpel.config.completionPersistPolicy">on</property>
<property name="bpel.config.inMemoryOptimization">true</property>
</component>
If both are same please suggest ,performance wise which one is the best one?In which table i have to check the stored payloads in the database?
Thanks in Advance!
Edited by: 851924 on Jul 2, 2012 4:50 AM

Disabling certificate-based login

Hello all,
does anybody know how to disable certificate-based login in SSL sessions? We are running iMS 5.2.1.
My webmail server should run on HTTPS but only accept password-based logins. Our users don't have certificates so certificate-based login is not needed. When I connect to webmail with Netscape Communicator 4.8 I get annoying message "No user certificate ... you do not have a Personal Certificate to authenticate yourself. The site may choose not to give you access without one."
Thanks, Vito

Yes it does.
I tried this.
Apparently, the server doesn't need to trust its own
certificate's CA
But remember that your clients MUST trust
your CA in order to avoid the popup window saying
that the certificate advertised by your server belongs to
an untrusted Certificate Authority
(add the CA's certificate to their personal database)
Good luck,
VIncent MAZARD

How do i disable jquery on login?

Hi !
Is there anyway i can disable jquery on login or edit page ? i would make the editing of accordions much easier.
Any help/suggestions is appreciated !
Kenneth Knudsen
Project Manager
Limited Edition DK Aps

Use typeof(parent.ice) == 'object' to check if the page is loaded inside the InContext Editing editor.
if (typeof(parent.ice) == 'undefined') {
//create accordion only when the page is not loaded by InContext Editing
$("#accordion").accordion();
Was this helpful to you?
Regards,Dan Popa

Disable oracle direct login

Hi ,
I know how to disable direct root login. but i have to disable direct root login for oracle.i am using Red Hat Enterprise Linux Server release 5.5 (Tikanga).
Can some one help me ...
Regards,
Ani

You might want to keep in mind though that "su" will break X11 xauth authentication (ssh -X). Having to login as another user is another password layer, but does not necessarily give you more control who gets access. It depends on your password policies and the users maintaining them. It might be a good idea to be careful who receives the Oracle password. Not every access to Oracle requires the Oracle account password or SYSDBA access.

Delay: KDE login and logout

Greetings everybody!
Being new to Arch my first post comes to address a minor nuisance, thats delaying start of KDE, shutting it down respectively.
Whats my issues?
After booting my system all those messages come up, "[DONE]" and such, and when KDM is supposed to start I am displayed a tty login for 5-10 secs. That tty is working, but no matter what, after that amount of time I am presented KDM, full working, that is after logging in I am entering KDE.
More or less the same goes for shutting down Arch from within KDE. Using the GUI there, the screen is greyish, and it takes rather long for actually shutting down KDE and showing me the tty messages (compared to Debian/Sid (aptosid), which is what I am used to).
Now I am wondering right about why there is that delay of being shown that tty instead of being given KDM at the start. And of course, why there is an (apparent) delay at shutting down KDE.
How did I install Arch?
I installed Arch using the basic netinstall release. I proceeded according to the wiki, installed X, proprietary nvidia driver and KDE. KDM I have included in my inittab.
[root@myhost phen]# cat /etc/inittab
# /etc/inittab
# Runlevels:
# 0 Halt
# 1(S) Single-user
# 2 Not used
# 3 Multi-user
# 4 Not used
# 5 X11
# 6 Reboot
## Only one of the following two lines can be uncommented!
# Boot to console
id:5:initdefault:
# Boot to X11
#id:5:initdefault:
rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin -p
# -8 options fixes umlauts problem on login
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux
# Serial Virtual Console for KVM and others VMs
#s0:2345:respawn:/sbin/agetty -8 9600 ttyS0 linux
# Hypervisor Virtual Console for Xen and KVM
#h0:2345:respawn:/sbin/agetty -8 38400 hvc0 linux
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
# Example lines for starting a login manager
#x:5:respawn:/usr/bin/xdm -nodaemon
#x:5:respawn:/usr/sbin/gdm -nodaemon
x:5:respawn:/usr/bin/kdm -nodaemon
#x:5:respawn:/usr/bin/slim >/dev/null 2>&1
# End of file
Since I suspect some service to cause that delay, heres my rc.conf.
[root@myhost phen]# cat /etc/rc.conf
# /etc/rc.conf - Main Configuration for Arch Linux
# LOCALIZATION
# LOCALE: available languages can be listed with the 'locale -a' command
# DAEMON_LOCALE: Set the locale during daemon startup and during the boot
# process. If set to 'no', the C locale will be used.
# HARDWARECLOCK: set to "UTC" or "localtime", any other value will result
# in the hardware clock being left untouched (useful for virtualization)
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
LOCALE="de_DE.UTF-8"
DAEMON_LOCALE="no"
HARDWARECLOCK="localtime"
TIMEZONE="Europe/Berlin"
KEYMAP="de-latin1-nodeadkeys"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
# HARDWARE
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=()
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
# NETWORKING
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
HOSTNAME="myhost"
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# DHCP: Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
INTERFACES=(eth0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
# Setting this to "yes" will skip network shutdown.
# This is required if your root device is on NFS.
NETWORK_PERSIST="no"
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
# Network profiles are found in /etc/network.d
# This now requires the netcfg package
#NETWORKS=(main)
# DAEMONS
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
DAEMONS=(syslog-ng dbus @network @netfs @crond @alsa appset-helper !usblp @wicd cups)
I am used to seeing the boot messages and afterwards KDM starts instantly. Having to look at an empty tty login screen for a couple of seconds before KDM starts is unusual to me. Again, this is merely a nuisance, not preventing me to use Arch, not to say KDE, but if this behaviour is not normal, where could I start to look for, in order to improve startup time?
Now, when I want to shutdown my system after KDE-session using that GUI option in the K-menu, it takes like almost half a minute of grey out screen for I am finally displayed the tty messages. In case this is not normal I would assume that might be caused by the same issue?
Any other file I need to show to you?
I hope anyone of you can give me some helpful advices.
Cheers!

phen wrote:I wonder though, having no umlauts in use for KDM but using european layouts (German that is, including .. well, Umlauts) - would that entry in inittab enable some sort of check just for that case umlaut-supporting layout is enabled?
Not quite sure what you're thinking of here. If by 'that entry in inittab' you mean, the one I singled out for commenting, what that one does is start a login prompt on tty1, pure and simple. The line after that start a prompt on tty2, the one after that a prompt on tty3, etc. I can say for certain, that inittab doesn't care a bit whether you use umlauts, and I doubt (but again can't say for sure) that KDM has any special concern for umlauts or not. If you want to properly understand what happens in the inittab, I very much recommend the arch wiki article on inittab. The inittab syntax is actually pretty easy to understand, and the wiki article is good.
phen wrote:What do you mean by "you do run a lot of services in the background mode prior to starting KDM"? I thought I have all services tagged to run in background assuming I dont have to run them prominently? The services entered I think I chose carefully, that is I need them. Anything I am doing wrong there?
Again, not quite sure I follow. I am not suggesting that you do not use the services, merely that you do not run start them in the background. Let me quote the wiki:
If a script is prefixed with an "at" symbol (@), then it will be executed in the background, i.e. the startup sequence will not wait for successful completion before continuing.
This is only useful in some instances, e.g. if a daemon needs to wait for a network connection. If the whole system was to pause while waiting for that connection to complete that would a major nuissance. So you background it. In most cases though we're waiting for the harddisk and so 'backgrounding' has no benefit.
The point of my suggestion though was not to tell you whether to use the '@' or not in general but to suggest not using it, while you tested the hypothesis that it was the daemons/background services that was causing the wait - and not KDM. Once that test was over, you should of course feel free to start using the @'s again, if your so prefer.
Last edited by madchine (2011-04-15 11:05:51)

MSI GS70 20D Touchpad not working after login when I upgraded to 8.1

Short situation: I upgraded my laptop to windows 8.1, and the touchpad stopped working on the start/desktop screens. I could move it before I logged in, and after it would work for a few seconds, but then it would just stop. An external mouse works just fine, but I still don't want my touchpad not working.
I looked on the MSI USA technical support page, and it said to delete the old drivers for the touchpad and download new ones. I deleted the drives, but every time I try to download the new ones, I get a window that says my touchpad isn't plugged in, and that the drive isn't compatible with my touchpad, which doesn't make sense to me because I looked up my product specifically and tried all three touchpad drivers. None of them worked.
Now I can't use the touchpad at all because I deleted the drivers, so it would seem that the computer doesn't know it has a touchpad because it won't register the touchpad in my devices tab.
Does anyone know what I can do to solve this? Or to at least get the touchpad to register again? I just got this computer for Christmas, I've treated it very well so it hasn't banged up against anything or been dropped or mistreated, so I cannot understand why this is happening. It worked before the 8.1 update, so I'm pretty sure the issue has something to do with that.

UPDATE: So I managed to fix the touch pad by deleting the driver and rebooting, which is weird because I removed the driver completely and never reinstalled it, so the computer shouldn't really know it has a touch pad. But every time I reboot the computer after fixing it, the touch pad goes back to it's old problem and I need to redelete and reboot all over again.
Also, My computer has begun to randomly freeze and not respond to anything, with one such event leading to a blue screen with a WHEA_UNCORRECTABLE_ERROR message. The computer has frozen a total of 6 times, at different moments; when I'm typing on microsoft word, at the login screen, even right when it starts up and the msi loading screen is up. 5 of these times have required a forced shut down, the first time the computer shut off on it's own because it ran out of battery power.
Finally, my computer has begun to periodically for long stretches of time stopped detecting wireless networks and is asking to be plugged into an ethernet cable to connect to the internet. This has never happened to me before, and I know I haven't turned off my network sharing center.
I'm not sure why this is all suddenly happening. It's not like I'm banging my laptop against walls. I'm very careful when I move and use my GS70, so these problems are greatly concerning to me because I just got this computer at Christmas.

A security question pertaining to disabling the root login. [SOLVED]

I've recently been configuring sudo and came across the following piece of advice:
https://wiki.archlinux.org/index.php/Su … root_login
After making my normal user a full fledged sudoer I followed the advice in the link above.
passwd -l root
worked beautifully without problems in spite of the warnings.
However on a hunch after going
ls -l /etc/passwd
I was dismayed to see that the permission of the file was 644 with owner root. Shouldn't the permission be 640? Otherwise why would a cracker try to guess who is a sudoer when you can look at /etc/passwd and see myname in the entries and go like "OK root's disabled this is the only other human user lemme see if I can crack this..."
Like I would have changed the permission on etc/passwd to 640 but since I'm far from an expert I want to know if this is safe to do/are there any unintended consequences for doing so. Furthermore even if I can do that the cracker will then proceed to search for all users who are members of the wheel group. I don't know what command would do this but clearly there must be a way the OS keeps track of which group has which members. Even if it's possible to safely change the permission of etc/group to 640 or 600 I don't think it's a good idea cause the cracker will still attempt to find all members of the wheel group because wheel is universal to Linux.
My next worry is /etc/shadow. The good news is the permission there is 600. However there may be other files which can give away my username to the cracker besides /etc/passwd and /etc/group. If so what are they. Can they be safetyed?
All in all was disabling root a good idea. I still want my normal user to have sudo powers for convenience. But even so if I am right about /etc/passwd then following the advice there simply makes the job one step longer for el cracker muy malo. Can you guys clue me in as to whether or not /etc/passwd can be safetyed without consequence and what is going on with this whole thing.
Last edited by hiushoz (2011-01-10 05:08:03)

I don't think you'll be able to change the permissions without error. If I'm not very much mistaken, several user-space programs (like xterms) read that to determine what your preferred shell is.
But if I understand the permissions system correctly doesn't the third number dictate access for people that aren't the owner or part of the owners group?
Yes, that's correct. However, there's no mechanism for them to view the files. Users can't execute processes (including the shell and its commands) unless they've either logged into your computer or found an exploit somewhere. In the event that they've found the exploit, they're most likely already running in either kernel mode or as root, so your security has already been compromised.
You're probably confused because of the oft-used terminology 'world readable'. In reality, that means any local user.
Why would you allow a cracker to login in the first place?
I think this about sums it up, though I would like to elaborate on what's really being said here. There are several ways to give a cracker access to your computer; the most obvious being granting them a user account and letting them sit at your keyboard. When you run a script or binary written by someone else, it's very close to the same thing. The program you're running can do everything you can.
Just as you wouldn't let someone you don't trust sit at your keyboard, you should only run scripts and binaries from users you trust, at least until you've gathered enough skill to scrutinize their contents. By installing the Arch distribution, it seems you already trust Arch and its repositories, so I wouldn't worry so much about those binaries.
Otherwise why would a cracker try to guess who is a sudoer when you can look at /etc/passwd and see myname in the entries and go like "OK root's disabled this is the only other human user lemme see if I can crack this..."
This is silly, for a number of reasons:
1) As above, the user would need to already be logged in as a local user.
2) There are dozens of other places where you can find lists of local users. Even if you were to change the permissions there, a cracker could easily find a list of probable human users by:
-Listing the contents of /home/.
-Reading the file /etc/group; this if anything is even more dangerous, as it hints at which users have administrative rights.
3) You're trying for security through obscurity. Instead of hiding the usernames, you should attempt to remove any vulnerabilities that would make knowing a username useful.
Perhaps you'd be better off preventing a brute force attack by monitoring /var/log/auth.log, perhaps with something like Fail2Ban?
Last edited by ktemkin (2011-01-10 02:23:38)

NCL and LUM gives: micasa broken and initial NCL login has scripts disabled at every login - so you have to change it manually after every reboot

I just made an interesting discovery.
I cloned an existing VM and moved it to another physical machine. This
machine was initially installed without LUM and as long as LUM was not
configured and only local authentication took place everything (NCL,
Micasa and integrated login) worked as documented.
After configuring LUM authentication, the following does not work:
Micasa (it does only work as long as the machine is up, after a restart
you have to enter passwords for all micasa enabled applications if you
use them for the first time during uptime)
NCL does not save the settings for scripts, they are always disabled by
default after the machine has come up. The settings for scripts do work
for all subsequent logins, just not for the first after booting the
machine.
The same behaviour is shown by another machine, which has LUM
configured for authentication.
Machines do not show this behaviour if using a local only user or if
LUM authentication is removed.
W. Prindl

W.,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your problem been resolved? If not, you might try one of the following options:
- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://support.novell.com/forums)
Be sure to read the forum FAQ about what to expect in the way of responses:
http://support.novell.com/forums/faq_general.html
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your Novell Product Support Forums Team
http://support.novell.com/forums/

Touchpad disabled on KDE login

Similar Messages

Maybe you are looking for