* Made KeyboardInputDevice more similar to MouseInputDevice, the object to
track individual keyboards has become the class KeyboardDevice. Moved
much functionality that used to be in KeyboardInputDevice into
KeyboardDevice.
Functionally, it should still be the same, but there are two important
changes:
- Each KeyboardDevice now has it's own Keymap. At first, it is not
visible by the user, since all KeyboardDevices still adopt the keymap
if the user reconfigures it. But it will make it easier to assign
individual keymaps to each attached keyboard (and perhaps associate them
with a vendor/product or some other means). The more immediate side effect
is that there is no longer a confusion about the keyboard locks. If
you press NumLock on your external keyboard, it will no longer enable
NumLock on your notebooks internal keyboard.
- KeyboardDevice now has a Stop() method, which it will call in it's
destructor. This will make sure that the control thread is cleanly
exited and does not end up invoking methods on a deleted object.
* Rewrote the tracing implementation in MouseInputDevice.cpp. At least it
helped track me down the following problem:
* Both KeyboardDevice and MouseDevice now set fActive to "false" *before*
closing the device. Since the control threads run at high priority, chances
are high that rescheduling happens as soon as the device unblocks in
ioctl() and returns an error. In that case, the control threads would
check fActive and it would still be "true" and the whole idea of bailing
out because we're already in Stop() would not work, causing a double free
in the end.
All of this is nice and more correct, but input_server is still crashing
when restarting it via "input_server -q"... :-(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28352 a95241bf-73f2-0310-859d-f6bbb57e9c96
device returned B_OK.
* In the InputServer destructor, don't check the fAddOnManager pointer,
but check the success of calling Lock() on it instead, which should
be much safer.
* In StartStopDevices(), really start or stop all published devices for
the given BInputServerDevice, not only the first one found. Simplify
the check whether anything needs to be done.
* Change a bit the return codes of StartStopDevices(). Especially the
version that's supposed to start or stop all devices will still try
to do it for the rest of them.
* Removed no longer needed _FindInputDeviceListItem().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28351 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it are unblocked and get an error.
* Make fOpen volatile to prevent unwanted caching effects when checking it from
different threads. (?)
* Check IsOpen() in the KeyboardDevice class in more acquire_sem_etc() return
cases, analogous to the MouseDevice class.
I am still getting a problem when relaunching input_server with the input_server
add-on thread that ioctl()s on a USB keyboard fd, which should have never fired
because it's a fake device from a KVM. After the first input_server instance is
gone, this thread keeps on busy looping in acquire_sem_etc()->switch_sem() from
within the ioctl() of the KeyboardDevice usb_hid driver. Still on it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28350 a95241bf-73f2-0310-859d-f6bbb57e9c96
at 0. A single AddPath()+RemovePath() would therefore leave a not
anymore needed path_entry(), while a AddPath()+AddPath()+RemovePath()
would remove/delete the path_entry while it was actually still used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28349 a95241bf-73f2-0310-859d-f6bbb57e9c96
a panic when ejecting a disc, since updating DMAResource isn't implemented
yet...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28348 a95241bf-73f2-0310-859d-f6bbb57e9c96
possible, ie. if no other volumes are mounted on the device.
* Fixed a operator precedence bug in GetSettings() when retrieving the mounted
volume flags.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28347 a95241bf-73f2-0310-859d-f6bbb57e9c96
that conveniently bridge BVolumes/mount points with BPartitions.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28346 a95241bf-73f2-0310-859d-f6bbb57e9c96
resulted in the keyboard not working (at least on my Lenovo/IBM T60).
The device control thread could become aware of a dead device
at the time another thread (for example the add-on manager thread)
is already waiting for it. Then it tried to remove the device and
got stuck on locks that the other thread already holds (InputDeviceItem
list lock). Now the control threads check the "active" flag before
trying to remove the devices themselves, which, when set, is a sure
sign that the devices are already being removed and they don't need
to take care of it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28342 a95241bf-73f2-0310-859d-f6bbb57e9c96
ide_mask_sector_count_48, and ide_mask_LBA_*_48 were all wrong.
* Using the high byte in LBA48 mode should work now, too (wasn't written
to the IDE controller before, but that shouldn't have been a problem yet with
today's disks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28340 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This fixes bug #2880, ie. make the ide_adapter write the IDE task file
correctly to the command register, CD-ROMs are working again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28339 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed some places that set an error return value but didn't actually
return.
* Fixed success case return value. The number of bytes received must be
returned, not B_OK.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28335 a95241bf-73f2-0310-859d-f6bbb57e9c96
ssize_t, not a status_t, so the following setting of the address length
was never invoked, causing recvfrom() to always return the passed in
size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28334 a95241bf-73f2-0310-859d-f6bbb57e9c96
stat::st_{dev,ino}.
* stat::st_rdev is unused, but at least initialize it with some
deterministing value. This makes Perl's lib/File/stat.t test happy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28333 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Various fixes and corrections
* Preparation for new sections
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28332 a95241bf-73f2-0310-859d-f6bbb57e9c96
tab width. This fixes the initially wrong tab width for windows where the title
does not fit and previously there would be 10 pixels waste on the right.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28331 a95241bf-73f2-0310-859d-f6bbb57e9c96
invalid rects (in ActivityView's case in particular, (-7, -7, 0, 0)). BDragger
would happily accept these, and preserve them when being archived/unarchived,
which led to its position being completely messed up in the target shelf.
We now compensate for this when determining our relationship with the target
view. This fixes the problems with missing replicant handles in BSnow,
ActivityMonitor and probably others replicants. The solution used here might
not be ideal though, so comments welcome.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28330 a95241bf-73f2-0310-859d-f6bbb57e9c96
tracker prefs via the preferences menu using a one line script: 'hey Tracker DO
Preferences'. Not sure how to set the icon of the script with the build system, feel
free to do it. See enhancement #2365
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use a derived text view that filters the tab key to avoid interupting tab
navigation while in focus/editing. Closes#2321
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28328 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When the device watcher/control thread encounteres an error when
read()ing or ioctl()ing the device, don't just quit the thread and
leave a stale device add-on hanging there, but instead trigger
_RemoveDevice() to exit this cleanly. This also takes care of calling
_RemoveDevice() only from one thread. However, it adds a race condition
should a mouse or keyboard be unplugged and plugged at the same time.
I need to think about how to fix that cleanly, although the situation
may be theoretical only... This fix seems to fix another problem with
hot-plugging USB mice, before this change, the first mouse entry in
/dev/input/mouse/usb/ was never gone and I got two entries after unplugging
and replugging.
* When using BObjectList configured to own the entries - don't delete the
entries! Also don't call RemoveItem() before still using the item. Took
me all day to find this one, because the code looked so... correct. :-}
* In _AddDevice() call _RemoveDevice() just for the sake of it. It is really
important that no device with the same name is published twice. The PS/2
driver behaves strange in that it publishes device more than once, if
I understand correctly, until it decides that there is no device.
* Only StartMonitoringDevice() /after/ having performed the initial device
scan! Or else we may get ourselves confused. I don't know if this was
an actual problem, but the code was like that before and it seems saner
to me. Seeing there is no locking in the device add-on itself, we may
already enter the code from the node monitor thread.
This should fix#2894.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28321 a95241bf-73f2-0310-859d-f6bbb57e9c96
device path, but instead pointing to memory owned by some device addon
instance.
* Added TODO in the AddOnManager init code about a possible race condition
which I have not varified yet.
* Check the return code of BList::RemoveItem() before deleting the item...
pure defensive programming.
* For the time being, print a warning into the syslog when a device name is
registered twice.
* When failing to Unflatten() an event, don't continue in the code after
deleting it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28319 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use new(nothrow) to allocate the MethodReplicant.
* fSignature needs to be free()d, not deleted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28318 a95241bf-73f2-0310-859d-f6bbb57e9c96
weird.
* Set fHandler to NULL in _UnregisterAddOns(), just in case it is called
twice (which it probably never is... but be defensive).
* If a B_NODE_MONITOR message does not contain all the necessary fields,
drop into the debugger when compiling in DEBUG mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28317 a95241bf-73f2-0310-859d-f6bbb57e9c96
devices that were removed. Should use the BPathMonitor anyways...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28315 a95241bf-73f2-0310-859d-f6bbb57e9c96
rethought and reimplemented with the layout system and my keymap management patch, but
the intent was to make it more usable in the mean time.
* Don't change the focus on keydown so that we can naviguate the list with the
keyboard.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28314 a95241bf-73f2-0310-859d-f6bbb57e9c96
things could be rewritten in a cleaner way but i'd rather finish my keymap
management patch as i rewrote the preflet for it anyway. For example the '(Current)'
item shouldn't be needed anymore but is still there in case the keymap:name attribute
read fails or if the original keymap file doesn't exist anymore (for example, applying
a user keymap, quiting the preflet, deleting the keymap file, and reloading the
preflet)
* Revert/apply data wasn't correctly loaded when the first load was on a system
keymap. This would allow revert/apply right after starting the preflet. That was the
cause of #2659.
* fCurrentMapName wasn't updated after a Revert or Apply
* Select the active keymap in the lists after reverting.
Quick cosmetical fix follows.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28313 a95241bf-73f2-0310-859d-f6bbb57e9c96
bfs_inode to store the link path (up to a certain length). If this was long
enough to clobber the data_stream::size field (which luckily was the last
field of struct data_stream), Inode::Free() would mistakenly assume this to
be a valid data stream to be freed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28311 a95241bf-73f2-0310-859d-f6bbb57e9c96
feels. This caused floating/modal app and subset windows to not work anymore.
* This fixes bug #2914.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28309 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed unloading the add-on image twice in error case of failing to
add the add-on info to the list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28307 a95241bf-73f2-0310-859d-f6bbb57e9c96
the wrong Link actions were used (always the no-attributes-support ones
which remove the target first), for instance.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28304 a95241bf-73f2-0310-859d-f6bbb57e9c96
* In this case, SoundRecorder shows a different error message, more informative, confer bug #134
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28303 a95241bf-73f2-0310-859d-f6bbb57e9c96
updates during the vertical refresh, but it causes flickering again since
there is no guarantee that screen regions will stay clean from the time that
they were scheduled with the UpdateQueue until the UpdateQueue thread
transfers them. Therefor it is still disabled.
* Refactored a bit the distinction between Invalidate() and CopyToFront().
Invalidate() used to be virtual, but now CopyToFront() is. This was mainly
needed for the app_server test environment, because the host window needs
to call Invalidate() when the front buffer bitmap is clean. When the
UpdateQueue is used, this needs to be CopyToFront(). Now the separation is
cleaner in combination with the UpdateQueue.
* Fixed a problem in HWInterface::CopyToFront(): When separating the region
outside the cursor and the region with the cursor during a transfer, it
needs to hold the fFloatingOverlay lock to make sure the cursor is not
moved in the meantime. This fixes graphics glitches with remnants of the
cursor staying on screen. These could very rarely be observed, but much more
often with the accelerated double-buffer mode.
* Enabled the accelerated double buffered mode, since it works now very well.
I was able to test it with the nVidea driver on an nVideo 7300. It works by
allocating a frame buffer twice the height of the configured screen mode.
Then all drawing goes into the offscreen portion, including accelerated
driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration
to blit the clean regions in the offscreen portion of the frame buffer into
the visible part. Please tell me if there are problems, for example when
if there is too few video memory, or if a driver does not handle it correctly.
To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96
François Revol