2016

关于PS4手柄(DS4)通过蓝牙连接的小问题(Win7,Win10 1703)

前几天修理了一个左模拟摇杆癫痫了的PS4手柄,换掉3D摇杆后问题解决,然后测试手柄时发现了这个神器:DS4Windows http://ds4windows.com/,用usb线连接手柄后可以检测手柄的大部分功能,比如光条(能改颜色哦)、重力感应、加速度等,还可以将PS4手柄模拟成Xbox 360的手柄,完美支持所有可用360手柄的PC游戏。另外,本人非常喜欢这次的DS4手柄改进,第一次拿在手里时就有一种说不出的舒适感(之后就再用PS2、PS3的就感觉有些不爽了,哈哈),再加上这个神器软件的存在,比当年PS3手柄的那个ScpServer要方便的多了!
后来发现神器作者的主页上还提到了可以支持蓝牙,正好手里有个N年前买的一个Broadcom 2046芯片的usb小蓝牙适配器,拿出来试试看无线效果如何,结果,问题来了:用PS+Share键开启DS4的强制配对后,蓝牙设备中可以看到Wireless Controller,连接后就是让确认了一下设备,也没让输什么0000的默认配对码,然后一瞬间手柄的光条从配对状态的短促快闪变成了已连接状态的常亮,然后Win端开始给设备安装驱动,再之后手柄光条灭掉,驱动装好后也没有连接上的无线手柄设备了,单按PS键后,Win端提示有设备请求连接,确认后就又断开了。
继续阅读…

CentOS 7 yum update中断重启后提示kernel panic-not syncing:VFS:Unable to mount root fs on unknown-block

今天更新VMWare上的CentOS 7时,不小心手滑在安装进行到一半左右时关掉了ssh连接,结果再回来时yum就不好了,显示提示有中断的操作,然后又是multilib,一通cleanup之后yum是不提示异常了,结果reboot后直接kernel panic异常,系统无法启动!

好在bootloader里的rescue还是可以进的,搜索了一下测试了下,最简单的解决方法是先

sudo yum remove kernel

sudo yum install kernel

然后再重新启动正常的kernel就可以进系统了,不过感觉由于yum update时中断导致的某些软件丢失或是版本不对的问题还是存在,等到用时再逐一解决吧。

VS结合VisualGDB搭建OpenWrt交叉编译远程调试开发环境

由于此开发环境涉及3设备协同工作,因此先说明一下整体开发环境的配置以及每部分所负责的功能:
1.Windows PC
这里我用的是64位Win7,作为VS的安装环境Windows自然是必不可少的,本机主要用于结合VisualGDB插件完成项目创建,上传编译机编译并部署执行程序到测试机完成gdbserver远程调试(自然是背后gdb前脸VS的全图形可视化调试)
2.Linux PC
这个我这里是CentOS Linux release 7.2.1511 64bit,安装于VMWare虚拟机上(当然也可以用真机,效果更佳!),作为交叉编译OpenWrt执行程序的编译机,由VisualGDB通过ssh连接同步Win机上的项目源码,make文件等并进行编译,同时还作为gdb客户端连接OpenWrt调试服务端并由VisualGDB传递gdb调试操作间接实现Win端的VS图形化调试
3.OpenWrt Router
这个我这里使用的是联想的Y1S路由器,MT7620A mips架构,作为整个开发环境的目标平台,接收Linux编译后的执行程序,并负责启动gdbserver作为远程调试的服务端

整体环境介绍完了,首先要做的是搭建起Linux机上的OpenWrt命令行开发环境(Y1S对应的是OpenWrt-SDK-ramips-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2),并且保证可以使用原始gdb的方式成功进行命令行模式的远程调试,这个就不赘述了,网上有很多相关教程。补充一点,在gdb调试过程中可能会遇到(OpenWrt上线./gdbserver :9876 /mnt/sda1/kcamd启动调试进程):

./scripts/remote-gdb 192.168.99.1:9876 ./build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/kcam/kcamd

This GDB was configured as “–host=x86_64-linux-gnu –target=mipsel-openwrt-linux-uclibc”.

(gdb) b main
Breakpoint 1 at 0x400cac: file main.cpp, line 29.
(gdb) c
Continuing.
warning: `/usr/lib/libstdc++.so.6′: Shared library architecture unknown is not compatible with target architecture mips:isa32r2.
warning: `/lib/libgcc_s.so.1′: Shared library architecture unknown is not compatible with target architecture mips:isa32r2.
warning: Could not load shared library symbols for 5 libraries, e.g. /lib/libuci.so.
Use the “info sharedlibrary” command to see the complete listing.
Do you need “set solib-search-path” or “set sysroot”?

Breakpoint 1, (gdb) n
Remote ‘g’ packet reply is too long: 00000000f8ffffffecdee77740b4ff7701000000f46dff7ffc6dff7f2034847fec6eff7f000101819bffaaacf0ffffff00031c7fffffffff00000000c826e677da6eff7f1c094000406dff7f0098e477f8e0a0000e00000000004400dc7a430087040000900c40000000000000000000a013e877786aff7f786aff7f4c27e67713ff0001a070230029000000a0d1e17724008050ac0c4000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)

继续阅读…

Android百度地图SDK文字覆盖物的换行和旋转中心点问题

百度地图的Android SDK中支持在地图上添加各种覆盖物,其中包括文字覆盖物TextOptions,但目前版本4.1.0中此功能不支持文字换行,且不可设置文字中心点,导致如果想要和其它覆盖物混合使用时,如在图标上显示一些文字时,效果很不好,由于只能通过对文字覆盖物的经纬度坐标添加一定的偏移来实现,例如下面这样:

                        // 定位坐标偏移
                        point = new LatLng(lat+0.0001, lng);
                        OverlayOptions textOption = new TextOptions()
                                .bgColor(0xAAFFFF00)
                                .fontSize(24)
                                .fontColor(0xFFFF00FF)
                                .text("test "+formatter.format(date))
                                .position(point);
                        // 在地图上添加该文字对象并显示
                        mBaiduMap.addOverlay(textOption);

继续阅读…

百度鹰眼SDK Android版后台服务的重绑定问题

Android版百度鹰眼SDK(测试版本2.1.15)在开启定位追踪时会开启com.baidu.trace.LBSTraceService的服务来完成后台的定位和上传数据功能,此时如果应用主Activity退出(用户自行关闭,或者被系统kill等情况)时,则需要在重启时检测是否已经开启了追踪服务并可以正确停止服务。按照官方文档的说明,这种情况下应该先通过startTrace()重新进行后台服务的绑定,可以收到“onTraceCallback: 10006, 服务已开启”的结果回调,但我的实际测试结果则是,后台服务运行的情况下,应用重启startTrace()不会收到任何回调!同时又做了几种其它情况下的服务开启关闭测试,结果如下:
在应用不退出重启的情况下,不管是用同样的Trace对象,还是每次都创建同样参数的新Trace对象,都可以顺利连续开启、关闭追踪服务。而在重启应用的状态下,检测到服务正在运行后,用新创建的同样参数的Trace对象尝试startTrace时会出现收不到任何回调的情况,而如果先在应用管理器中手动停止后台服务再startTrace就没问题。
在应用重启的情况下,重新new一样参数的Trace对象,然后调用stopTrace,这样得到的回调结果是“onStopTraceFailed: 11002, 服务未开启”,但此时getRunningServices确实能够查到正在运行的后台服务。又试了通过stopService的方式直接请求停止com.baidu.trace.LBSTraceService服务,此时返回的是true,但getRunningServices依然可以检测到服务正在运行。
附上测试用的检测后台服务运行状态的方法:

    public boolean isTraceServiceRunning() {
        ActivityManager manager = (ActivityManager) getActivity().getSystemService(ACTIVITY_SERVICE);
        for (ActivityManager.RunningServiceInfo service : manager.getRunningServices(Integer.MAX_VALUE)) {
            if ("com.baidu.trace.LBSTraceService".equals(service.service.getClassName())) {
                return true;
            }
        }
        return false;
    }

最后,在联系了官方后,得到了问题的解决方法:
继续阅读…

内网Visual Studio Code通过XDebug远程调试linux服务器PHP脚本

开发环境是这样:一台位于内网环境下的Windows机器使用VSCode作为IDE编写PHP脚本项目,一台位于公网的linux服务器运行lighttpd、fastcgi PHP用于部署调试。开发机所在网络环境不允许或不方便进行端口映射来打开XDebug所需的本地调试监听端口(默认9000),同时也不想安装本机PHP服务器来调试,于是采用本机编写PHP,然后上传linux服务器直接远程调试,记录环境搭建过程如下:
首先配置好开发机的IDE环境,我用的是VSCode 1.6.1,然后安装PHP Debug扩展,完成后选择一个指定文件夹作为项目根目录并在调试页中新建PHP调试配置,这时会在项目文件夹中生成.vscode/launch.json配置文件,按照PHP Debug的说明,加入serverSourceRoot与localSourceRoot,参考如下:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "serverSourceRoot": "/var/www/lighttpd/phpproj",
            "localSourceRoot": "${workspaceRoot}"
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000,
            "serverSourceRoot": "/var/www/lighttpd/phpproj",
            "localSourceRoot": "${workspaceRoot}"
        }
    ]
}

其中serverSourceRoot为项目位于服务器端的存储位置完整路径,localSourceRoot为本地项目存储位置完整路径,一般用环境变量${workspaceRoot}即可表示项目根目录。
继续阅读…

Xcode升级后导致原Qt项目构建失败的问题

原有使用Qt Creator 4.0.2创建的跨平台GUI项目,在近日Xcode升级至8.0后,出现了构建失败的问题,错误信息如下:

clang: warning: no such sysroot directory: ‘/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk’
In file included from ../FbxVertexMerger/main.cpp:1:
In file included from ../FbxVertexMerger/mainwindow.h:4:
In file included from ../../../../Qt5.7.0/5.7/clang_64/lib/QtWidgets.framework/Headers/QMainWindow:1:
In file included from ../../../../Qt5.7.0/5.7/clang_64/lib/QtWidgets.framework/Headers/qmainwindow.h:43:
In file included from /Users/wzkres/Qt5.7.0/5.7/clang_64/lib/QtWidgets.framework/Headers/qwidget.h:43:
In file included from /Users/wzkres/Qt5.7.0/5.7/clang_64/lib/QtGui.framework/Headers/qwindowdefs.h:43:
In file included from /Users/wzkres/Qt5.7.0/5.7/clang_64/lib/QtCore.framework/Headers/qglobal.h:81:
/Users/wzkres/Qt5.7.0/5.7/clang_64/lib/QtCore.framework/Headers/qsystemdetection.h:95:12: fatal error: ‘TargetConditionals.h’ file not found
# include <TargetConditionals.h>

显然,问题出在MacOSX10.11.sdk这个位置,升级后的MacOSX SDK变为了MacOSX10.12.sdk,那么如何让Qt使用新版本的SDK呢?很简单,修改Qt项目的.pro文件,加入 继续阅读…

VC++项目中第三方库代码生成std::string对象的析构崩溃问题

在使用预编译好的第三方库时,一定要注意生成库时的Runtime Library运行时库是否与引用库项目所使用的一致,一般提供prebuilt库方都会按照这些规则给库文件命名,如mt、mt-d等。
这次在测试一个别人提供好的mongo库时,就遇到了由于运行时库不一致导致的莫名其妙崩溃问题,崩溃代码如下:

mongo::BSONObjBuilder builder;
builder.append("type", 2)
mongo::BSONObj obj = builder.obj();
obj.jsonString();

在jsonString()这一步,任何BSONObj的转std::string方法,如toString()等,构造出的std::string在析构时会导致崩溃,大致看了下是标准库中的析构函数内执行此处时触发的:

__CLR_OR_THIS_CALL ~basic_string()
    {   // destroy the string
    _Tidy(true);
    }

放开运行的话会提示堆已被破坏,修改了一些调用代码方式,无果,最后发现自行创建的std::string析构时执行同样逻辑没有问题,最终发现是由于dll库使用的是debug版运行时库,而主程序使用的是非debug运行时库所致,在VS中Configuration properties->C/C++->Code Generation->Runtime Library,选择一致的debug版运行时库后,问题解决。

Unity3D导入TTF生成文字图集的跨平台不确定性问题

Unity3D中,TTF字体可以以动态或静态方式使用,其中静态方式可以通过指定某些字符(某个字符集或者自定义的一些字符)生成文字图集材质及贴图,类似下图这样:
QQ截图20160815092800
而这次要说的问题就出在这个文字图集的贴图上,具体情况是在TTF设置同样的Font Size,Rendering Mode,Character和Custom Chars(使用Custom set字符集模式)的情况下,Unity Editor在不同系统下(Windows和Mac OSX)生成的贴图不一致的问题:
ttf1
可以看到,同一个“格”字生成了不同的字模(朝向、位置都有些许变化)。这个问题,如果是文字图直接拿来用的话还好,但要做一些手脚的话,比如手动修改贴图,实现一些如渐变,描边等艺术字效果的话就会引起麻烦,图集信息不同,要不就得改两次贴图,要不就会显示错乱。
继续阅读…

CentOS 7下编译FBX SDK示例时的”cannot find -luuid”问题

在Linux环境下尝试编译FBX SDK中的samples时,最后链接时出现”cannot find -luuid”,查了下文档发现这个uuid库是linux下生成唯一id用的那么一个库,起初以为是少了什么lib或者devel之类的,于是用yum开始安装,结果libuuid、uuid-devel都装上了还是不行,于是又都逐一卸载掉,查看ld的search path,在/lib64/下找到了:

lrwxrwxrwx. 1 root root 16 4月 7 22:35 /lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x. 1 root root 20032 4月 1 01:37 /lib64/libuuid.so.1.3.0

用yum确认了下,也确实是已安装有这个uuid相关的库以及include等,于是怀疑是符号链接的问题,试了下用

ln -s libuuid.so.1 libuuid.so

建立libuuid.so的符号链接,重新make,成功通过并生成了sample的执行文件。

PS: FBX SDK的sample中的MakeFile将CC和LD设置成了gcc4,这个在我的CentOS7下会找不到(默认安装的应该都是),于是直接删掉了4。